TENT COOPERATION TRE^ 



KU/UfcUU/UlbW 



From the INTERNATIONAL BUREAU 



PCT 

NOTIFICATION OF ELECTION 

{PCT Rule 61.2) 


To: 

Commissioner 

US Department of Commerce 
United States Patent and Trademark 
Office, PCT 

201 1 South Clark Place Room 

Arlington, VA 22202 
ETATS-UNIS D'AMERIQUE 

in its capacity as elected Office 


Date of mailing (day/month/year) 
07 March 2001 (07.03.01) 




International application No. 
PCT/DE00/01552 


Applicant's or agent's file reference 
SAP109/0A/W0 


International filing date (day/month/year) 
13 May 2000 (13.05.00) 


Priority date (day/monthly ear) 
18 June 1999 (18.06.99) 


Applicant 

PAULY, Heinz et al 



1. The designated Office is hereby notified of its election made: 

| X| in the demand filed with the International Preliminary Examining Authority on: 

10 January 2001 (10.01.01) 

| | in a notice effecting later election filed with the International Bureau on: 



2. The election 



m 
□ 



was 
was not 



t 



made before the expiration of 19 months from the priority date or, where Rule 32 applies, within the time limit under 
Rule 32.2(b). ' 



BEST AVAILABLE COPY 





The International Bureau of WiPO 
34. chemin des CoJombettes 
1211 Geneva 20. Switzerland 

Facsimile No.: (41-22) 740.14.35 


Maria Kirchner 

Telephone No.: (41-22) 338.83.38 



Form PCT/IB/331 (July 1992) 



DE0001552 
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C^iBER DIE INTERNATIONALE ZUSAUI 
^■F DEM GEBIET DES PATENTW^p 

PCT 

INTERNATIONALER RECHERCHENBERICHT 

(Artikel 18 sowie Regeln 43 und 44 PCT) 



MENARBEIT 
NS 



Aktenzeichen des Anmelders Oder Anwalts 

99-16-PCT 


WEITERES siehe Mitteilung uber die Obermittiung des intemationalen 

Recherchenberichts (Formblatt PCT/ISA/220) sowie, soweit 
VORGEHEN zutreffend, nachstehender Punkt 5 


Internationales Aktenzeichen 
PCT/DE 00/02902 


Internationales Anmeldedatum 
(T ag/Monat/Jahr) 

25/08/2000 


(Fruhestes) Prioritatsdatum (Tag/Monat/Jahr) 

30/08/1999 


An m elder 

ORGA KARTENSYSTEME GMBH et al . 



Dieser Internationale Recherchenbericht wurde von der Interna tionalen Recherchenbehorde erstellt und wird dem Anmelder gemaB 
Artikel 18 ubermittelL Eine Kopie wird dem Intemationalen Buro ubermittelt. 

Dieser international Recherchenbericht umfafM insgesamt _2 Blatter. 

|X| Dartiber hinaus liegt ihm jeweils eine Kopie der in diesem Bericht genannten Unterlagen zum Stand der Technik bei. 



1 . Gru n dlage des Beri chts 

a. Hinsichtlich der Sprache ist die internationale Recherche auf der Grundlage der intemationalen Anmeldung in der Sprache 
durchgefuhrt worden, in der sie eingereicht wurde, sofern unter diesem Punkt nichts anderes angegeben ist. 

| | Die internationale Recherche ist auf der Grundlage einer bei der Behorde eingereichten Ubersetzung der intemationalen 
Anmeldung (Regel 23.1 b)) durchgefuhrt worden. 

b. Hinsichtlich der in der intemationalen Anmeldung often barten Nucleoid- und/oder Aminosauresequenz ist die internationale 
Recherche auf der Grundlage des Sequenzprotokolls durchgefuhrt worden, das 

| | in der intemationalen Anmeldung in Schriflicher Form enthalten ist. 

zusammen mit der intemationalen Anmeldung in computerlesbarer Form eingereicht worden ist. 
bei der Behorde nach tragi ich in schriftlicher Form eingereicht worden ist. 
bei der Behorde nach tragi ich in computerlesbarer Form eingereicht worden ist. 

Die Erklarung, daB das nach tragi ich eingereichte schriftliche Sequenzprotokoll nicht uber den Often barungsge halt der 
intemationalen Anmeldung im Anmeldezeitpunkt hinausgeht, wurde vorgelegt 

Die Erklarung, daB die in computerlesbarer Form erfaBten Informationen dem schriftlichen Sequenzprotokoll entsprechen, 
wurde vorgelegt. 

Bestimmte Ansp ruche haben sich als nicht recti erchierbar erwiesen (siehe Feld I). 
Mangelnde Einheitfichkeit der Erfindung (siehe Feld II). 



□ 
□ 
□ 
□ 

□ 



2. 
3. 



□ 
□ 



4. Hinsichtlich der Bezeichnung der Erfindung 

[X| wird der vom Anmelder eingereichte Wortlaut genehmigt. 
| | wurde der Wortlaut von der BehOrde wie folgt festgesetzt: 



5. Hinsichtlich der Zusammenfassung 

rj^[ wird der vom Anmelder eingereichte Wortlaut genehmigt 

— wurde der Wortlaut nach Regel 38.2b) in der in Feld III angegebenen Fassung von der Beh8rde festgesetzt. Der 

| | Anmelder kann der Behorde innerhalb eines Monats nach dem Datum der Absendung dieses intemationalen 

Recherchenberichts eine Stellungnahme vorlegen. 

6. Folgende Abbildung der Zeichnungen ist mit der Zusammenfassung zu verOffentlichen: Abb. Nr. _] 



flT| wie vom Anmelder vorgeschlagen [^| keine der Abb. 

| | weil der Anmelder selbst keine Abbildung vorgeschlagen hat. 
| | weil diese Abbildung die Erfindung besser kennzeichnet. 



Formblatt PCT/ISA/210 (Blatt 1 ) (Juli 1998) 



INTERNATIONALER RECHERCHENBERICHT 



A. KLASSIFI2ERUNG DES ANMELDUivGSGEGENSTANDES 

IPK 7 G06K1/12 



Nach der Intemationalen Pate ntkfassjfikal ion (IPK) oder nacfi der nationalen Klassifikation und der IPK 



I Internationales Aktenzeichen 

j^T/DE 00/02902 



B. RECHERCHIERTE GEBIETE 



Recherchierter Mindestprufstoff (Klassiftkationssyslem und Klassifikationssymbole ) 

IPK 7 G06K B41M G11B 



Recherchierte aber nicht zum Mindestprufstoff gehorende Veroffentlichungen. soweit diese unter die recherchierten Gebiete fallen 



W ah rend der intemationalen Recherche konsultierte elektronische Oatenbank (Name der Datenbank und evtl. verwendete Suchbegriffe) 

EPO-Internal , PAJ, WPI Data 



C. ALS WESENTLICH ANGESEKENE UNTERLAGEN 



Kategorie 0 Bezeichnung der Verdffenllichung. sowert ertorderfich unter Angabe der in Betracht kommenden Teile 



Betr. Anspmch Nr. 



WO 97 48016 A (C0RNIGLI0N ISABELLE 
; LERICHE CHRISTIAN (FR); GELLIS ARMAND 
(FR); S) 18. Dezember 1997 (1997-12-18) 
das ganze Dokument 



W0 97 16318 A (KAMMANN MASCHF WERNER 

; HASTINGS STEPHEN ALAN (GB)) 

9. Mai 1997 (1997-05-09) 

Seite 8, Zeile 23 -Seite 9, Zeile 20 

W0 89 05730 A (PUGSLEY JOAN LEGAL 
REPRESENTAT ;DE LA RUE CO PLC (GB)) 
29. Juni 1989 (1989-06-29) 
Seite 8, Zeile 7 -Seite 14, Zeile 24 
Abbildungen 1-5 



1,2,5-8, 
10 



9 
9 



1,2,5-8, 
10 



□ 



Weitere Ver&flentlichungen sind der Fortsetzung von Feld C zu 
entnehmen 



ID 



Siehe Anhang Palentfamllie 



° Besondere Kategorien von angegebenen Veroffentlichungen 
■A* Veroffentlichung, die den allgemeinen Stand der Technik defmiert, 
aber nicht ate besortders bedeutsam anzusehen ist 

'E* alteres Dokument, das |edoch erst am oder nach dem intemationalen 
An me kle datum verdffentlicht worden ist 

'L' Veroffentlichung, die geeignet ist, einen Prioritatsanspruch zweifelhaft er- 
scheinen zu lassen, oder durch die das Verdffentlichungsdatum erner 
anderen im Recherchen benefit genannten Verdffenllichung belegt werden 
soli Oder die aus einem anderen besonderen Grund angegeben ist (wie 
ausgefuhrt) 

'O* Veroffentlichung. die sich auf eine mundliche Offenbarung, 

eine Benutzung. eine AussteDung oder andere Mafinahmen beziehl 

*P* Veroffentlichung, die vor dem internalionalen AnmekJe datum, aber nach 
dem beanspruchten Prioritatsdatum veroffentlichl worden ist 



•T* Spatere Veroffentlichung, die nach dem intemationalen AnmekJedatum 
Oder dem Prioritatsdatum verSffentlicht worden ist und mil der 
Anmeldung nicht kollidiert, sondem nur zum Verstandnis des der 
Erfindung zugrundeliegenden Prinzips oder der ihr zugrundeliegenden 
Theorie angegeben ist 

■X' VerSffentlichung von besonderer Bedeutung; die beanspruchte Erfindung 
kann aDein aufgrund dieser Veroffentlichung nicht ate neu Oder auf 
erfinderischer Tatigkeit beruhend betrachtet werden 

"Y" Veroffentlichung von besonderer Bedeutung; die beanspruchte Erfindung 
kann nicht als auf erfinderischer Tatigkeit beruhend betrachtet 
werden. wenn die Veroffentlichung mil einer oder mehreren anderen 
VerSffentlichungen dieser Kategorie in Verbindung gebracht wird und 
diese Verbindung fur einen Fachmann nahetiegend ist 

'&* Verdffenllichung, die Mitgtted derselben Patentfamilie ist 



Datum des Abschlusses der internalionalen Recherche 



21. Marz 2001 



Absendedalum des intemationalen Recherchenberichts 



28/03/2001 



Name und Postanschrffl der Intemationalen Rechercnenbehdrde 
Europaisches Paten tamt, P. B. 5818 Palentlaan 2 
NL - 2280 HV Rijswijk 
Tel. (+31-70) 340-2040. Tx. 31 651 epo nl. 
Fax: (+31-70) 340-3016 



Bevonmachtigter Bediensteter 



de Ronde, 0. 



Fwmbtatt PCT/ISA/210 (BbB 2) (Juii 1 992) 



INTERNATIONAL SEARCH REPORT 

Inf^fc^tion on patent f amity members 



Patent document 
cited in search report 



Publication 
date 



International Application No 

'DE 00/02902 



Patent family 
member(s) 



Publication 
date 



FR 


2749673 


A 


12-12-1997 


AT 


190735 


T 


15-04-2000 


BR 


9709705 


A 


10-08-1999 


CN 


1227636 


A 


01-09-1999 


DE 


69701468 


D 


20-04-2000 


DE 


69701468 


T 


10-08-2000 


EP 


0912916 


A 


06-05-1999 


ES 


2147003 


T 


16-08-2000 


HU 


0002137 


A 


28-10-2000 


JP 


2000512033 


T 


12-09-2000 


US 


6107010 


A 


22-08-2000 



WO 9748016 



18-12-1997 



W0 9716318 A 09-05-1997 NONE 



W0 8905730 A 29-06-1989 EP 0391964 A 17-10-1990 



Form PCT/ISA/2 10 (patent family annex) (Juty 1992) 
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VERTRAG UBE»IE INTERNATIONALE ZUsJWlMENARBEIT AUF DEM 

GEBIET DES PATENTWESENS 



PCT 



INTERNATIONALER VORLAUFIGER PRUFUN 

(Artikel 36 und Regel 70 PCT) 




recd 2 0 JUL 2001 



PCT 



Aktenzeichen des Anmelders oder Anwalts 
SAP 109/OA/WO 


\wcitcdcc wad^cucu siehe Mittei,un 9 uber die Obersendung des internationalen 
WfclTfcHES VORGEHEN voriaufigen Prufungsberichts (Formblatt PCT/IPEA/416) 


Internationales Aktenzeichen 
PCT/DE00/01552 


Internationales Anme\dedatum(Tag/Monat/Jahr) 
13/05/2000 


Prioritatsdatum (Tag/Monat/Tag) 
18/06/1999 



Internationale Patentktassifikation (IPK) oder nationale Klassifikation und IPK 
G06F17/00 



Anm elder 

SAP AKTIENGESELLSCHAFT et al. 



1 . Dieser internationale vorlaufige Prufungsbericht wurde von der mit der internationalen voriaufigen Prufung beauftragten 
Behorde erstellt und wird dem Anmelder gemaB Artikel 36 ubermitteit. 



2. Dieser BERICHT umfaRt insgesamt 5 Blatter einschlieBlich dieses Deckblatts. 

□ AuRerdem tiegen dem Bericht ANLAGEN bei; dabei handelt es sich um Blatter mit Beschreibungen, Anspruchen 
und/oder Zeichnungen, die geandert wurden und diesem Bericht zugrunde liegen, und/oder Blatter mit vor dieser 
Behorde vorgenommenen Berichtigungen (siehe Regel 70.16 und Abschnitt 607 der Verwaltungsrichtlinien zum PCT) 



Diese Anlagen umfassen insgesamt Blatter. 



3. Dieser Bericht enthalt Angaben zu folgenden Punkten: 



IV 

V 

VI 
VII 
VIII 



S Grundlage des Berichts 

□ Prioritat 

□ Keine Erstellung eines Gutachtens uber Neuheit, erfinderische Tatigkeit und gewerbliche Anwendbarkeit 

□ Mangelnde Einheitlichkeit der Erfindung 

H Begrundete Feststellung nach Artikel 35(2) hinsichtlich der Neuheit, der erfinderischen Tatigkeit und der 
gewerblichen Anwendbarkeit; Unterlagen und Erklarungen zur Stutzung dieser Feststellung 

□ Bestimmte angefuhrte Unterlagen 

S Bestimmte Mangel der internationalen Anmeldung 

S Bestimmte Bemerkungen zur internationalen Anmeldung 



Datum der Einreichung des Antrags 
10/01/2001 


Datum der Fertigstellung dieses Berichts 
18.07.2001 


Name und Postanschrift der mit der internationalen voriaufigen 
Prufung beauftragten Behorde: 

Europaisches Patentamt 
/flj) D-80298 Munchen 
ZZr' Tel. +49 89 2399 - 0 Tx: 523656 epmu d 
Fax: +49 89 2399 - 4465 


Bevollmachligter Bediensteter ><35o5£v 
Jaedicke, M (( ^) }) 

Tel. Nr. +49 89 2399 2357 



Formblatt PCT/I PEA/409 (Deckblatt) (Januar 1994) 
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INTERNATIONALER VORLAUFIGER 

PRUFUNGSBERICHT Internationales Aktenzeichen PCT/DE00/01 552 



I. Grundlage des Berichts 

1 . Hinsichtlich der Bestandteile der internationalen Anmeldung (Ersatzblatter, die dem Anmeldeamt auf eine 
Auffordemng nach Artikel 14 hin vorgefegt wurden, ge/ten im Rahmen dieses Berichts als "ursprunglich 
eingereicht" und sind ihm nicht beige fugt, weii sie keine Anderungen enthatten (Regeln 70. 16 und 70. 17)): 
Beschreibung, Seiten: 

1-49 ursprungliche Fassung 

Patentanspruche, Nr.: 

1 -24 ursprungliche Fassung 

Zeichnungen, Blatter: 

1/15-15/15 ursprungliche Fassung 



2. Hinsichtlich der Sprache: Alle vorstehend genannten Bestandteile standen der Behorde in der Sprache, in der 
die internationale Anmeldung eingereicht worden ist, zur Verfugung oder wurden in dieser eingereicht, sofern 
unter diesem Punkt nichts anderes angegeben ist. 

Die Bestandteile standen der Behorde in der Sprache: zur Verfugung bzw. wurden in dieser Sprache 
eingereicht; dabei handelt es sich um 

□ die Sprache der Ubersetzung, die fur die Zwecke der internationalen Recherche eingereicht worden ist (nach 
Regel 23.1(b)). 

□ die Veroffentlichungssprache der internationalen Anmeldung (nach Regel 48.3(b)). 

□ die Sprache der Ubersetzung, die fur die Zwecke der internationalen voiiaufigen Prufung eingereicht worden 
ist (nach Regei 55.2 und/oder 55.3). 

3. Hinsichtlich der in der internationalen Anmeldung offenbarten Nucleotid- und/oder Aminosauresequenz ist die 
internationale vorlaufige Prufung auf der Grundlage des Sequenzprotokolls durchgefuhrt worden, das: 

□ in der internationalen Anmeldung in schriftlicher Form enthalten ist. 

□ zusammen mit der internationalen Anmeldung in computerlesbarer Form eingereicht worden ist. 

□ bei der Behorde nachtraglich in schriftlicher Form eingereicht worden ist. 

□ bei der Behorde nachtraglich in computerlesbarer Form eingereicht worden ist. 

□ Die Erklarung, daB das nachtraglich eingereichte schriftliche Sequenzprotokoll nicht uber den 
Offenbarungsgehalt der internationalen Anmeldung im Anmeldezeitpunkt hinausgeht, wurde vorgelegt. 

□ Die Erklarung, daB die in computerlesbarer Form erfassten Informationen dem schriftlichen 
Sequenzprotokoll entsprechen, wurde vorgelegt. 

4. Aufgrund der Anderungen sind folgende Unterlagen fortgefallen: 



Formblatt PCT/IPEA/409 (Felder l-VIII, Blatt 1) (Juli 1998) 
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(USPTQ) 




INTERNATIONALER VORLAUFIGER 

PRUFUNGSBERICHT Internationales Aktenzeichen PCT/DE00/01 552 



□ Beschreibung, Seiten: 

□ Anspruche, Nr.: 

□ Zeichnungen, Blatt: 

5. □ Dieser Bericht ist ohne Berucksichtigung (von einigen) der Anderungen erstetlt worden, da diese aus den 
angegebenen Grunden nach Auffassung der Behorde uber den Offenbarungsgehalt in der ursprunglich 
eingereichten Fassung hinausgehen (Regel 70.2(c)). 

(Auf Ersatzbtatter, die solche Anderungen enthalten, ist unter Punkt 1 hinzuweisen;sie sind diesem Bericht 
beizufugen). 



6. Etwaige zusatzliche Bemerkungen: 



V. Begrundete Feststellung nach Artikel 35(2) hinsichtlich der Neuheit, der erfinderischen Tatigkeit und der 
gewerblichen Anwendbarkeit; Unterlagen und Erklarungen zur Stutzung dieser Feststellung 

1. Feststellung . \* 

Neuheit (N) Ja: Anspruche 1-24 

Nein: Anspruche 

Erfinderische Tatigkeit (ET) Ja: Anspruche 1 -24 

Nein: Anspruche 

Gewerbliche Anwendbarkeit (GA) Ja: Anspruche 1 -24 

Nein: Anspruche 

2. Unterlagen und Erklarungen 
siehe Beiblatt 



VII. Bestimmte Mangel der internattonalen Anmeldung 

Es wurde festgestellt, daB die internationale Anmeldung nach Form Oder Inhalt fotgende Mangel aufweist: 
siehe Beiblatt 



VIII. Bestimmte Bemerkungen zur internationalen Anmeldung 

Zur Klarheit der Patentanspruche, der Beschreibung und der Zeichnungen Oder zu der Frage, ob die Anspruche 
in vollem Umfang durch die Beschreibung gestutzt werden, ist folgendes zu bemerken: 
siehe Beiblatt 



Formblatt PCT/I PEA/409 (Felder I- VIII. Blatt 2) (Juli 1998) 
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INTERNATIONALER VORLAUFIGER Internationales Aktenzeichen PCT/DE00/01 552 
PRUFUNGSBERICHT - BEIBLATT 



Zu Punkt V 

Begrundete Feststellung nach Regel 66.2(a)(ii) hinsichtlich der Neuheit, der 
erfinderischen Tatigkeit und der gewerblichen Anwendbarkeit; Unterlagen und 
Erklarungen zur Stiitzung dieser Feststellung 

1 . Es wird auf die folgenden Dokumente verwiesen: 

D1: US-A-5 873 096 (LIM PETER S ET AL) 16. Februar 1999 (1999-02-16) in 

der Anmeldung erwahnt 
D2: US-A-5 870 765 (BODGE ANDREW ET AL) 9. Februar 1999 (1999-02-09) 

2. Das Verfahren zur Datenpflege in einem offline-verteilten Datenbank-Netzwerk 
gemaB Anspruch 1 ist neu und erfinderisch (Artikel 33(1) PCT), weil keines der 
Dokumente D1 und D2 eine Verteilung von Anderungsinformationen vorsieht, bei 
der die Replikationsobjekte mit Hilfe einer Lookup-Tabelle adressiert werden und 
diese Lookup-Tabelle unter Berucksichtigung der Anderungsinformationen in 
einem Realignment-Algorithmus aktualisiert wird. 

Wahrend sowohl D1 als auch D2 Verfahren zur Unterstutzung der 
Datenkonsistenz in offline-verteilten Datenbanksystemen mit partieller Replikation 
behandeln, existieren deutliche Unterschiede zwischen den Verfahren. 

Der in der Anmeldung bereits gewurdigte nachstliegendste Stand der Technik D1 
verwendet zur Verteilung von Anderungsinformationen von der zentralen 
Datenbank an die Knotendatenbanken Sichtbarkeitsregeln anstelle einer Lookup- 
Tabelle. Da es sich urn verschiedene, nicht-aquivalente Techniken handelt 
besteht schon hierin ein erfinderischer Unterschied zu D1 . 

D2 lehrt weder ein unterschiedliches Vorgehen bei On- und Offlinebetrieb, noch 
die Verwendung von Ausgangsschlangen. Ein Realignment von Lookup-Tabellen 
wird in D2 ebenfalls nicht offengelegt, da die Datenverteilung auf der Ebene von 
Tabellen als Granulat erfolgt und somit Datenanderungen keinen EinfluB auf die 
Verteilungsinformation in einer Lookup-Tabelle haben konnen. Somit besteht auch 
gegenuber D2 und gegenuber einer moglichen Kombination von D1 und D2 klar 
ein erfinderischer Unterschied. 



Formblatt PCT/Betblatt/409 (Blatt 1) (EPA-April 1997) 



INTERNATIONALER VORLAUFIGER Internationales Aktenzeichen PCT/DE00/01 552 
PRUFUNGSBERICHT - BEIBLATT 



3. Die Anspruche 2-24 umfassen alle technischen Merkmale des Anspruchs 1 und 
sind somit ebenfalls neu und erfinderisch (Artikel 33(1) PCT). 

4. Alle Anspruche sind industriell anwendbar (Artikel 33(1) PCT), z.B. auf dem 
Gebiet der kommerziellen Datenverarbeitung. 

Zu Punkt VII 

Bestimmte Mangel der internationalen Anmeldung 

1 . Der unabhangige Anspruch 1 ist nicht in der zweiteiligen Form nach Regel 6.3 b) 
PCT abgefaBt. Im vorliegenden Fall erscheint die Zweiteilung unter 
Berucksichtigung der aus dem Stand der Technik bekannten Merkmale (siehe 
Dokument D1) jedoch zweckmaBig. 

2. Der Abschnitt der Beschreibung auf Seite 25, Zeilen 11-14, worin die Anmeldung 
durch Bezugnahme auf ein weiteres Dokument erganzt werden soil, ist unklar. 

Zu Punkt VIII 

Bestimmte Bemerkungen zur internationalen Anmeldung 

1 . Der in Anspruch 2 verwendete Begriff "offentliche" Datenmenge ist unklar (Artikel 
6 PCT), weil es sich nicht urn einen allgemein ublichen technischen Fachbegriff 
handelt, dessen in der Anmeldung definierte Bedeutung (siehe Beschreibung, 
Seite 1 1 , Zeilen 4-6) als bekannt vorausgesetzt werden konnte. 

2. Die Abhangigkeit von Anspruch 13 ist unklar (Artikel 6 PCT). Es scheint, daf3 der 
Anmelder spezifizieren wollte, daB sich dieser Anspruch auf den Anspruch 8 in 
Kombination mit einem der Anspruche 1 1 oder 12 bezieht. 



Formblatt PCT/Beiblatt/409 (Blatt2) {EPA- April 1997) 



PAGE BLANK (uspto) 



(12) NACH DEM VERTRAO^^ER DIE INTERNATIONALE ZUSAMMENA^^^T AUF DEM GEBEET DES 
PATENTWESENS (PCT) VER6FFENTLICHTE INTERNATIONALE ANMELDUNG 



(19) Weltorganisation fur geistiges Eigentum 
Internationales Biiro 

(43) Internationales Veroffentlichungsdatum 
28. Dezember 2000 (28.12.2000) 




PCT 



liMDDlIUlllIHIIiUi 

(10) Internationale Ver6Qentlichungsnummer 

WO 00/79408 A2 



(51) Internationale Paten tklassifikation 7 : 



(21) Internationales A ktenzeichen: 



G06F 1 7/00 (71 ) An meld er (fur alle Bestimmungsstaalen mit Ausnahme von 
US): SAP AKTIENGESELLSCHAFT [DE/DE]; Neu- 
rottstrasse 16, 69190 Walldorf (DE). 



PCT/DE00/01552 



(22) Internationales Anmeldedatum: 

13. Mai 2000 (13.05.2000) 



(25) Einreichnngssprache: 



Deut&ch 



(72) Erfinden nnd 

(75) Erfinder/Anmelder (mar fur US): PAULY, Heinz 
[DE/DE]; Ellerstadter Strasse 34, 67071 Lud- 
wigshafen (DE). BRENDLE, Rainer [DE/DE]; Adal- 
bert-Seifiriz-Strasse 28, 69161 Neckargemund (DE). 



(26) Veroffentlichungssprache: 



Deutsch (74) Anwalte: PFEIFER, Hans-Peter usw.; Bciertheimer 
Allee 19, 76137 Karlsruhe (DE). 

(30) A n ga ben zur Prioritlt: 

199 28 035.5 18. Juni 1999 (18.06.1999) DE (81) Bestimmungsstaaten (national): AE, AL, AM, AT. AU, 



99120009.8 



14. Oktober 1999 (1 4. 1 0. 1 999) EP 



AZ, BA, BB, BG, BR, BY, CA, CH, CN, CR, CU, CZ, DE, 
[Fortsetzung auf der ndchsten Seite] 



== (54) Title: METHOD FOR DATA CARE IN A NETWORK OF PARTIALLY REPLICATED DATABASE SYSTEMS 

=== (54) BezeichDung: VERFAHREN ZUR DATENPFLEGE IN EINEM NETZWERK TEILWE1SE REPLIZIERTER DATENBANK- 
^= SYSTEME 



2>8W 



9 Lrr-*S2 




MTPJS 



(57) Abstract: A method for data care in an online distributed database network system (DBNS) comprising a central system (OS) 
with a central database (CD) and a plurality of node systems (NS) with local data bases (LD), whereby the local databases (LD) con- 
tain at least partially different subsets of data from the central database (CD), update data for the information stored in the databases 

fs| (CD, LD) of the database network system- (DBNS) is captured in a plurality of node systems (NS), and the update information is 

^ transferred from the node systems to the central system or from the central system to the node systems- when an online link exists - 
in the form of replication objects which are structured into different types containing an identification key. When no online link is 

0© available, said replication objects are placed in an output line for transmission at a later point in time. The replication objects with 
the update information in the central system (CS) in a replication algorithm are allocated with the aid of at least one lookup table 

^ (LUT) to the node systems where they are supposed to be transferred to as adressees, and the at least one lookup table is updated by 
taking into account the update information in a realignment algorithm. 



(57) Znsammenfassnng: Verfahren zur Datenpflege in einem offline- verteilten Datenbank-Netzwerksystem (DBNS), welches ein 
Zentralsystem (CS) mit einer zentralen Datenbank (CD) und eine Mehrzahl von Knotensystemen (NS) mit lokalen Datenbanken (LD) 
urnfa&t, wobei die lokalen Datenbanken (LD) imndestens teilweise unterschiedtiche Teilmengen der Daten der zentralen Datenbank 

[Fortsetzung auf der ndchsten Seite] 
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(CD) enthalten, Anderungsinformationen zu den in den Datenbanken (CD, LD) des Datenbank-Netzwerksystems (DSNS'* sesne 
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Verfahren zur Datenpflege in einem Netzwerk teilweise 
replizierter Datenbanksysteme 

Die Erfindung betrifft ein Verfahren zur Datenpflege in 
einem Netzwerk teilweise replizierter Datenbanksysteme, 
insbesondere relationaler Datenbanksysteme. Gegenstand 
der Erfindung ist auch ein nach einem solchen Verfahren 
arbeitendes Datenbanksystem, ein Computerprogrammprodukt 
fur ein solches Datenbanksystem sowie ein Datentrager mit 
einem solchen Computerprogrammprodukt . 

Datenbanken, insbesondere relationale Datenbanken, werden 
vielfach zur Verwaltung von Daten eingesetzt, die in 
Datenverarbeitungsanlagen verarbeitet werden. In relatio- 
nalen Datenbanken bilden die Daten eine Vielzahl zwei- 
dimensionaler Tabellen, die eine Relation beschreiben. 
Eine Tabelle kann sich z.B. auf ein Objekt und diesem Ob- 
jekt eindeutig zuordenbare Daten beziehen. Beispielsweise 
konnen die Kundendaten eines Unternehmens in einer Ta- 
belle "Kunde" gespeichert sein, deren Spalten unter- 
schiedliche Attribute der Kunden (Name, Adresse, An- 
sprechpartner, Umsatze etc.) betreffen. Die Werte unter- 
schiedlicher Kunden bilden die Reihen der Tabelle. Nicht 
nur Objekte, sondern auch Beziehungen zwischen Objekten 
werden in relationalen Datenbanken als Tabellen darge- 
stellt. Wenn beispielsweise ein Auftrag fur einen be- 
st immten Kunden ausgefuhrt wird, enthalt die zur 
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Verwaltung der Auftrage generierte Tabelle "Auftrag" ein 
Attribut "fur Kunde", durch die die Beziehung Kunde-Auf- 
trag definiert wird. Derartige Pointer spielen zur Dar- 
stellung von Beziehungen zwischen Objekten, die durch un- 
terschiedliche Tabellen einer Datenbank beschrieben wer- 
den, eine groSe Rolle. 

Infolge der weiten Verbreitung von tragbaren Rechnern 
(Laptops) stellt sich vielfach die Aufgabe, die auf einem 
zentralen Datenbanksystem (Datenbankserver) hinterlegten 
Daten auf eine Vielzahl von lokalen Datenbanksystemen, 
die beispielsweise auf Laptops installiert sind, zu re- 
plizieren. Die lokale Datenbank des Laptops wird von des- 
sen Benutzer offline (ohne standige Verbindung zu dem 
zentralen Datenbankserver) benutzt. Dabei werden die Da- 
ten nicht nur aus der lokalen Datenbank abgerufen, son- 
dern auf Basis lokal gewonnener Inf ormationen auch gean- 
dert, erganzt Oder geloscht. 

Ein typisches Beispiel sind Kundenbetreuungssysteme, die 
auch als SPA (Sales Force Automation)- oder CRM (Customer 
Relation Management) -Systeme bezeichnet werden. Derartige 
Systeme sind besonders auf die EDV-Anforderungen der Kun- 
denberatung, Kundenbetreuung und des Vertriebs zuge- 
schnitten. Hierzu gehort , daS die AuSendienstmitarbeiter 
des Unternehmens mit einem Laptop ausgeriistet werden, der 
in einer eigenen lokalen Datenbank alle Daten enthalt, 
die der jeweilige AuSendienstmitarbeiter (beispielsweise 
aufgrund seines Vertriebsgebietes und der von ihm betreu- 
ten Kunden) benStigt . 

Die Erfindung bezieht sich allgemein auf offline -ver- 
teilte Datenbank-Netzwerke, bei denen die Speicherung der 
Daten in mehreren Datenbanksystemen unterschiedlicher 
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Computer (verteilt) erfolgt, die nicht standig miteinan- 
der verbunden (offline) sind. Selbstverstandlich konnen 
an solchen Datenbank - Net zwerken als lokale Datenbank - 
systeme auiSer Laptops andere stationare oder mobile Rech- 
nersysteme mit jeweils eigenen Datenbanken beteiligt 
sein. 

In einem of f line-verteilten Datenbank-Netzwerk werden die 
Daten zwischen den beteiligten Datenbanksystemen ubli- 
cherweise durch Nachrichten (Messages) ausgetauscht . In 
einer sogenannten Hub-Struktur erfolgt der Austausch der 
Messages sternformig, d.h. Nachrichten werden von den lo- 
kalen Datenbanksystemen nur an das zentrale Datenbank - 
system ubermittelt, dort verarbeitet und im erforderli- 
chen Umfang an andere lokale Datenbanksysteme des Netz- 
werkes ("Knoten") weitergeleitet . Ein direkter Datenaus- 
tausch zwischen den lokalen Datenbanksystemen findet in 
einem Datenbank-Netzwerk mit Hub-Struktur nicht statt. 

Nachfolgend wird das zentrale Datenbanksystem als Zen- 
tralsystem bezeichnet. Fur die lokalen Datenbanksysteme 
des Datenbank- Net z we rkes wird die Bezeichnung Knoten- 
systeme verwendet . 

Die Erfindung bezieht sich insbesondere auf ein Daten- 
bank-Netzwerk mit Hub-Struktur. Selbstverstandlich kann 
dieses Datenbank-Netzwerk bzw. konnen die daran be- 
teiligten Datenbanksysteme mit weiteren Computersystemen 
vernetzt sein, zwischen denen die Daten nicht in einer 
Hub-Struktur ausgetauscht werden. Die Knotensysteme des 
erf indungsgemaSen Datenbank- Net zwerksys terns konnen auch 
selbst zugleich das Zen tral system eines nachgeordneten, 
ebenfalls sternformig organisierten, Datenbank -Net z we rk- 
systems sein, so da£ eine Baumstruktur entsteht . 
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In der Regel werden die an dem erf indungsgemaSen Daten- 
bank-Netzwerk beteiligten Computersysteme nicht nur ein 
Datenbanksystem, sondern auch andere Anwendungen enthal- 
ten, die unmittelbar (ohne Berucksichtigung der Hub- 
Struktur) miteinander kommunizieren. Notwendig ist je- 
doch, dafi der Datenaustausch, der zur Pflege der an dem 
Datenbank-Netzwerk beteiligten Datenbanken notwendig ist, 
in der beschriebenen Weise sternformig erf olgt . 

Mit der Pflege of f line-verteilter Datenbank-Netzwerke 
sind schwierige Probleme verbunden. 

Die lokalen Datenbanken der Knotensysteme k6nnen und sol- 
len keine vollstandige Kopie der zentralen Datenbank 
sein. zum einen reicht die Speicherkapazitat hierftir in 
der Regel nicht aus. Zum zweiten wurde die standige 
Pflege von Daten, die in den Knotensystemen nicht wirk- 
lich benotigt werden, zu inakzeptablen Rechen- und Ver- 
bindungszeiten fuhren. SchlieElich sprechen Sicher- 
heitsprobleme dagegen, umfassende Daten eines Unterneh- 
mens vielfach vollstandig zu replizieren. Daraus resul- 
tiert die Aufgabe, die zentrale Datenbank des Zentral- 
systems in den lokalen Datenbanken der Knotensysteme se- 
lektiv teilweise so zu replizieren, daf5 jedem Knoten- 
system die jeweils von ihm bendtigten Daten zur Verfugung 
stehen. 

Ein weiteres Problem resultiert daraus, daS Datenanderun- 
gen in unterschiedlichen Teilsystemen des Netzwerks regi- 
striert werden, die fur andere Teilsysteme bedeutsam sind 
und im Rahmen der Datenpflege (Data Maintenance) in deren 
Datenbanken eingearbeitet werden mussen. Beispielsweise 
wird eine Datenanderung lokal registriert, wenn ein Au- 
Sendienstmitarbeiter einen AbschluS macht und demzufolge 
in der Datenbank seines Knotensystems einen Auftrag 
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generiert, wenn er einen neuen Ansprechpartner bei einem 
Kunden in die Datenbank aufnimmt und den bisherigen An- 
sprechpartner loscht oder wenn er eine Adresse eines Kun- 
den andert. Diese Beispiele zeigen, daS alle drei in der 
Datenbanktechnik ublichen Anderungsoper at ionen Neuanlage 
("Insert"), Modifikation ("Update") und Loschung 
{ "Delete") lokal anf alien. Aufierdem werden Anderungs- 
informat ionen in der Regel in groSem Umfang in der zen- 
tralen Datenbank verarbeitet, beispielsweise wenn sich 
Produktdaten (die selbstverstandlich auch von den Aufien- 
dienstmitarbeitern benotigt werden) andern, neue Produkte 
eingefuhrt oder bisherige Produkte geloscht werden. Nach- 
folgend wird als zusammenf assende Bezeichnung der den Da- 
tenbankoperat ionen Update, Insert und Delete zugrundelie- 
genden Informat ionen der Begriff "Ande rungs in format ionen" 
verwendet . 

Die Notwendigkeit , lokale Anderungen in jeder der betei- 
ligten Datenbanken zuzulassen, fuhrt dazu, dafi die Da- 
tenintegritat zwischen dem Zentral system und den Knoten- 
systemen (d.h. die Konsistenz der an dem Gesamt system be- 
teiligten Datenbanken) mit zunehmender Zahl der erfolgten 
Anderungen abnimmt . Urn die Datenkonsistenz zu gewahrlei- 
sten, ist es notwendig, die Inhalte der of f line-verteil- 
ten Datenbanken von Zeit zu Zeit in Ubereinstimmung zu 
bringen. Da Datenanderungen in jedem an dem Datenbank- 
Netzwerk beteiligten Computersystem vorgenommen werden 
konnen, mussen die geanderten bzw. erganzten Daten in der 
zentralen Datenbank und den lokalen Datenbanken miteinan- 
der verglichen und in dem erf orderlichen Umfang geanderte 
bzw. neue Daten ausgetauscht werden. An diesen Datenaus- 
tausch sind unter anderem folgende Anf orderungen zu stel- 
len : 

Alle Updates mussen genau denjenigen Teilnehmem des 
Gesamtsystems, die sie benotigen, mitgeteilt werden; 
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- neue Daten miissen in alle lokalen Datenbanken, die sie 
benotigen, eingearbeitet werden (Insert) und 
alle Daten, die in einem der Teilsysteme nicht mehr 
benotxgt werden, imissen geloscht werden (Delete) . 

Permit der Pflege of f line-verteilter Datenbank-Netzwerke 
verbundene Datenaustausch ist infolge dieser Anforderun- 
gen auSerordentlich komplex, insbesondere wenn man be- 
rucksichtigt, daS an dem Netzwerk eine grofie Anzahl von 
Computersystemen beteiligt sein kann. Infolge der weltum- 
spannenden Tatigkeit intemationaler Organisationen haben 
offlxne-verteilte Datenbank-Netzwerke teilweise mehrere 
tausend oder sogar mehrere zehntausend Teilnehmer. 

in dem US-Patent 5,873,096 ist ein Verfahren beschrieben, 

61 dem dle ^^^ingsinformationen zwisohen dem Zentral- 
system und den Knotensystemen mittels eines Datenkon- 
strukts ubertragen werden, das als Docking Object be- 
zexchnet wird. Das Docking Object enthalt (in Form von 
Identxfikationsschlusseln (Identifiers) als Verweis auf 
entsprechende Datenbankinhalte) die Anderungsinf ormation 
und zugleich die Verteilungsinformation, welche die 
Adressaten der Anderungsinf ormation bestimmt, also fest- 
legt, an welche Knotensysteme die jeweils in dem Docking 
Object enthaltene Anderungsinformation ubermittelt werden 
soil. Diese Verteilungsinformation wird als -visibility 
rules" bezeichnet. Alle Anderungsinf ormationen in dem ge - 
samten Datenbank-Netzwerk werden durch entsprechende 
Ubertragungs- und Mischprozesse in einem zentralen 
Anderungsregister (Central Update Log) zusammengefalSt und 
von dort - innerhalb des Zentralsystems - auf Teil- 
register (Partial Update Logs) verteilt, deren Anzahl der 
Anzahl der Knotensysteme entspricht . Diese Verteilung ge - 
schieht dadurch, daS auf jede Datenanderung die 
Visibility Rules fur jedes einzelne Knotensystem (also 
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fur N-Knotensysteme N mal) angewandt werden. Dabei kann 
es sich entweder urn eine unmittelbare Anwendung einer als 
SQL-SQL-Statement codierten Vert ei lungs regel handeln oder 
es erfolgt ein Verweis auf ein "Related Docking Object". 
Letzteres gilt in Fallen, bei denen die Anderungsinf orma- 
tion des gerade behandelten Docking Objects in gleicher 
Weise an die Knotensysteme verteilt wird, wie bei dem 
Related Docking Object. Die auf diese Weise in den Teil- 
regi stern gesammelten Anderungsinf ormati one n werden an 
die einzelnen Knotensysteme ubertragen, wenn diese eine 
Verbindung zu dem Zentralsystem herstellen. 

Durch dieses Verfahren, das einer Filterung der in dem 
zentralen Anderungsregister enthaltenen Daten mittels der 
"visibility rules" entspricht, konnen in dem Gesamtsystem 
alle Datenanderungen (Update, Insert und Delete) selektiv 
nach vorgegebenen Regeln an die Knotensysteme verteilt 
werden. Das Verfahren ist jedoch unflexibel, insbesondere 
hinsichtlich der Anpassung des Da t enbank - Ne t z we rk systems 
an unterschiedliche Anf orderungen . Aufierdem ist es sehr 
aufwendig hinsichtlich der erf orderlichen Rechenzeiten . 
Bei Datenbanksystemen mit einer grofien Zahl von Knoten- 
systemen wird deswegen die Performance unzureichend. 

Der Erfindung liegt auf dieser Basis die Aufgabe zu- 
grunde, ein verbessertes Verfahren zur Verteilung der er- 
forderlichen Anderungsinf ormationen an die Knotensysteme 
eines of f line-verteilten Da t enbank -Netzwerks zur Verfii- 
gung zu stellen. 

Die Aufgabe wird gelost durch ein Verfahren zur Daten- 
pflege in einem of f line-verteilten Da t enbank -Net zwerk- 
systems, welches ein Zentralsystem mit einer zentralen 
Datenbank und eine Mehrzahl von Knotensystemen mit loka- 
len Datenbanken umfafct, wobei die lokalen Datenbanken 
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mindestens teilweise unterschiedliche Teilmengen der 
Daten der zentralen Datenbank enthalten, Anderungsinf or- 
mationen zu den in den Datenbanken des Datenbank-Netz- 
werksystems gespeicherten Daten in einer Mehrzahl der 
Knotensysteme erfafit werden, die Anderungsinf ormationen 
bex bestehender Online -Verbindung als in mehreren unter- 
schiedlichen Typen strukturierte , einen Identif ikations- 
schlussel enthaltende Replikationsobjekte von den Knoten- 
systemen zu dem Zentralsystem oder von dem Zentralsystem 
zu den Knotensystemen ubertragen werden, die Replika- 
tionsobjekte bei fehlender Online -Verbindung in einer 
Ausgangsschlange fur eine spatere ©bertragung bereit- 
gastellt werden, die Replikationsobjekte mit den Ande- 
rungsinf ormationen in dem Zentralsystem in einem Replika- 
tions-Algorithmus mittels mindestens einer Lookup-Tabelle 
den Knotensystemen, an die sie ubermittelt werden sollen 
als Adressaten zugeordnet werden und die mindestens eine' 
Lookup-Tabelle unter Berucksichtigung der Anderungsinfor- 
mationen in einem Realignment -Algorithmus aktualisiert 
wird. 

Die Erfindung wird nachfolgend anhand eines in den Figu- 
ren dargestellten Ausf uhrungsbeispiels naher erlautert . 
Die m diesem Zusammenhang beschriebenen Besonderheiten 
der Erfindung konnen einzeln oder in Kombination verwen- 
det werden, urn bevorzugte Ausgestaltungen der Erfindung 
zu schaffen. Es zeigen: 

Fig. 1 eine schematische Darstellung wesentlicher Ele- 
mente der Architektur eines erf indungsgemaSen 
Datenbank-Netzwerksystems ; 

Fig. 2 die Struktur von im Rahmen der Erfindung ver- 
wendeten Replikationsobjekten (BDocs) ; 
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Fig. 3 ein Ablauf schema eines Programmoduls zur Be- 

handlung von lokal (in einem Knotensystem) ge- 
wonnenen Anderungsinf ormationen; 

Fig. 4 ein Ablauf schema eines Verbindungsmanagers , der 
die temporare Verbindung zwischen einem Knoten- 
system und dem Zentralsystem herstellt und 
uberwacht ; 

Fig. 5 ein Ablauf schema der Bearbeitung von BDocs in 
dem Zentralsystem mittels einer Flufisteuerung; 

Fig. 6 ein Ablauf schema einer Replication des Typs 
"Bulk-Replikation" ; 

Fig. 7 ein Ablauf schema einer Replikation des Typs 
"intelligente Replikation"; 

Fig. 8 ein Ablauf schema einer Replikation des Typs 
"abhangige Replikation"; 

Fig. 9 einen ersten Teil eines Ablauf schemas eines 
Realignment -Programmoduls ; 

Fig. 10 eine Fortsetzung des Ablauf schemas von Figur 9; 

Fig. 11 einen ersten Teil eines Ablauf schema eines Pro- 
grammoduls zur Durchfuhrung des Inter linkage- 
Realignment von Fig. 10; 

Fig. 12 eine Fortsetzung des Ablauf schemas von Fig. 11; 

Fig. 13 ein Ablauf schema eines Extractor- Programmoduls ; 

Fig. 14 ein Ablauf schema eines Bulk-Subskriptionspruf - 
moduls ; 

Fig. 15 ein Ablauf schema eines Objekt-Subskriptions- 
pruf moduls . 

Figur 1 gibt einen Uberblick uber die Architektur eines 
erf indungsgemafien Datenbank-Netzwerksystems DBNS (Data 
Base Network System) , das aus einem Zentralsystem CS 
(Central System) und einer Mehrzahl von Knotensystemen NS 
(Node System) besteht. Es kann sich beispielsweise urn ein 
CRM-System handeln, wobei die Knotensysteme NS vor allem 
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durch die Laptops der AuSendienstmitarbeiter des Unter- 
nehmens gebildet werden. Sie werden auch als mobile Kli- 
enten des Systems bezeichnet . Der AuSendienstmitarbeiter 
kann Inf ormationen (beispielsweise Bestellinf ormationen) 
in sein Knotensystem NS eingeben und erf orderliche Daten 
(beispielsweise uber die von ihm bearbeiteten Kunden und 
deren Auftrage) in seinem Knotensystem NS abrufen. Urn 
diese Funktionen temporar autonom erfullen zu konnen 
sind alle hierfur erf orderlichen Daten in einer lokalen 
Datenbank LD (Local Data Base) gespeichert. 

An dem Datenbank-Netzwerksystem konnen aufier mobilen Kli- 
enten auch andere Systeme als Knotensysteme beteiligt 
sein, so beispielsweise stationare Computersysteme des 
Unternehmens oder von Kunden, die entweder standig 
(online) oder temporar (offline) mit dem Zentralsystem CS 
verbunden sind. Auf diesem Wege konnen beispielsweise un- 
mittelbare Bestellungen der Kunden ohne Mitwirkung eines 
AuSendienstmitarbeiters abgewickelt werden. Auch die 
Datenbanken solcher weiterer Computersysteme konnen 
lokale Datenbanken LD des in Hub-Struktur organisierten 
erfmdungsgemafien Datenbank-Netzwerksystems DBNS bilden 
(wobei sie zugleich in andere Netzwerke eingebunden sein 
konnen) . 

In den Knotensystemen NS werden (unabhangig voneinander) 
Anderungsinf ormationen generiert, die auch fur das Zen- 
tralsystem CS und andere Knotensysteme NS bedeutsam sind 
Je nach der konkretene Systemkonf iguration kdnnen weitere 
Anderungsinformationen in dem Zentralsystem CS selbst ge- 
neriert werden. Das Zentralsystem sorgt dafur, daS jedes 
Knotensystem die notwendige und zulassige Information 
erhalt. Seine zentrale Datenbank CD wird auch als konso- 
lidaerte Datenbank (Consolidated Data Base) bezeichnet, 
weil sie den (hinsichtlich des Datenaustausches zwischen 
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den an dem Datenbank-Netzwerksystem DBNS beteiligten 
Datenbanken) "of f entlichen" Inhalt aller lokalen Daten- 
banken LD der Knotensysteme NS (zum Zeitpunkt des let z ten 
Datenaustausches) enthalt . Als "of f entlich" werden dabei 
Daten bezeichnet, die in dem Datenbank-Netzwerksystem 
ausgetauscht werden. Selbstverstandlich konnen die loka- 
len Datenbanken daneben Inf ormationen enthalten, die fur 
alle anderen Beteiligten des Da tenbank-Netzwerk systems 
CBNS ohne Bedeutung und deswegen "nicht off entlich" sind. 
Die zentrale Datenbank CD ermoglicht es, die lokalen 
Datenbanken LD jeweils mit den erf orderlichen Daten zu 
versorgen und, falls notwendig, auch die lokalen Daten- 
banken LD wiederherzustellen. 

Die Knotensysteme NS werden in Abstanden, beispielsweise 
am Abend jeden Tages, uber geeignete Kommunika t ionswege 
(z.B. Telefonleitungen, das Internet oder ein Intranet) 
mit dem Zentralsystem CS verbunden. Dabei werden die seit 
der let z ten Verbindung gesammelten Daten an das Zentral- 
system CS ubertragen. Aufierdem ubernimmt das Knotensystem 
NS bei dieser Gelegenheit seine eigenen verarbeiteten Da- 
ten des jeweils vorausgegangenen Zeitraums und neu einge- 
gebene Daten anderer Knotensysteme NS oder des Zentral- 
systems CS . 

Der gesamte Datenf lufi zwischen den Anwendungsprogrammen 
AS (Application Software) und den lokalen Datenbanken LD 
der Knotensysteme NS lauft uber einen in den Knotensyste- 
men implement ierten Transaction Layer TL. Dadurch konnen 
samtliche Anderungen der lokalen Datenbank LD, bevor sie 
persistent gemacht werden, registriert werden. Auch der 
Datentransfer aus dem Zentralsystem CS in die Knoten- 
systeme NS erfolgt ausschlieSlich uber deren Transaction 
Layer TL. 
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Der Transaction Layer TL ist transparent, d.h. die Anwen- 
dungsdaten, die von dem Anwendungsprogramm AS an die lo- 
kale Datenbank LD ubergeben werden, werden durch den 
Transaction Layer TL nicht geandert . Ausgangsseitig kann 
der Transaction Layer plattf ormubergreif end mit unter- 
schiedlich implement ierten lokalen Datenbanken LD zusam- 
menarbeiten. 

In dem Beispielsf all eines CRM- Systems beziehen sich die 
innerhalb des Datenbank-Netzwerks ausgetauschten Daten 
auf geschaftliche Vorgange, wie beispielsweise Kunden, 
Auftrage und dergleichen. Sie werden deshalb als 
Businessdaten bezeichnet. Der Datenaustausch in dem Da- 
tenbank -Net z we rksys tern DBNS erfolgt mittels struktu- 
rierter, ein Identif ikationsmerkmal (ID-Schlussel) auf- 
weisender Replikationsobjekte, die als «BDoc» bezeichnet 
werden. Die BDocs sind Datencontainer mit einer jeweils 
fur einen BDoc-Typ vorgegebenen Struktur, wie nachfolgend 
noch naher erlautert wird. Sie bilden die atomare Einheit 
der Replikation in dem Datenbank-Netzwerksystem DBNS . 
Beispielsweise enthalt ein BDoc fur einen bestimmten Auf- 
trag Daten, die zu dem Auftrag gehoren, unabhangig davon 
wie diese in der logischen Struktur der beteiligten Da- 
tenbanken LD und CD (als Tabellen einer relationalen Da- 
tenbank) vorliegen. Die Steuerdaten, die fur die Funktion 
der Knotensysteme NS und des Zentralsystems CS erforder- 
lich sind, sind in einem logisch gesonderten Teil der je- 
weiligen Datenbanken LD bzw. CD gespeichert, der als 
Repository bezeichnet wird. 

Bei dem in Figur l dargestellten Ausf uhrungsbeispiel 
steht das Zentralsystem CS mit einem weiteren System in 
Verbindung, das als OLTP-R/3 bezeichnet ist. OLTP-R/3 ist 
ein ERP (Enterprise Resource Planning) -System der SAP AG, 
Walldorf , Deutschland. Solche ERP-Systeme ermoglichen die 
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EDV-Unterstutzung unterschiedlichster Unternehmensberei- 
che, wie beispielsweise Personal, Vertrieb, Lagerhaltung 
etc. auf Basis einer gemeinsamen Datenbank, die in Figur 
1 als OLTP-DB bezeichnet ist. Das Zentralsystem CS des 
Datenbank -Netzwerksys terns DBNS kann beispielsweise uber 
ein LAN (Local Area Network) mit dem ERP- System OLTP-R/3 
verbunden sein. 

Soweit nachfolgend die fur die Ubermittlung der Ande- 
rungsinf ormationen verwendeten Replikationsobjekte als 
"BDoc", das Zentralsystem als "CRM-System" und das mit 
dem Zentralsystem CS verbundene ERP-System als "OLTP-R/3 " 
bezeichnet werden, geschieht dies beispielhaft ohne Be- 
schrankung der Allgemeinheit . Die beschriebenen Besonder- 
heiten gel ten allgemein fur die im Rahmen der Erfindung 
verwendeten Funktionen entsprechender Replikationsobjekte 
und Computersysteme auch in anderen Sof tware-Umgebungen . 

Die Datenubermittlung zwischen den Knotensystemen NS und 
dem Zentralsystem CS - optional auch zu weiteren externen 
Systemen - erfolgt mittels eines Funktionsmoduls, der als 
qRFC (Queued Remote Funktion Call) bezeichnet wird. Dabei 
handelt es sich urn einen Fernaufruf (Remote Call) , bei 
dem durch zusatzliche intelligente Merkmale sicherge- 
stellt wird, daS qRFCs in einer Schlange nacheinander be- 
arbeitet und dabei fur mehrere Calls benotigte gemeinsame 
Daten nur einmal gespeichert werden. 

Die Datenverarbeitung in dem Zentralsystem CS erfolgt mit 
Hilfe von Programmodulen, die als "Service" bzw. als 
"Adapter" bezeichnet werden. Ein Service stellt eine be- 
stimmte Funktion, die auf ein BDoc angewendet werden 
kann, zur Verfugung. Ein Adapter ist ein spezieller Typ 
von Service, der zusatzlich die Verbindung zu einem ex- 
ternen System ermoglicht. Fur jedes externe System 
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existiert ein eigener Adapter, der im Zusammenhang mit 
dem BDoc-Modelling auf Basis von Repository-Eintragen 
spezifisch fur den jeweiligen BDoc-Typ generiert wird. Er 
dient dazu, das Protokoll und die Datenstruktur des ex- 
ternen Systems fur das Zentralsystem CS zu ubersetzen. 

Die Flufisteuerung FC (Flow Control) ist die zentrale Kom- 
ponente des CS-Systems. Sie bewirkt auf Basis von FluS- 
definitionen FD die Verarbeitung von BDocs, indem sie 
eingehende BDocs in der richtigen Reihenfolge an die 
Services und Adapter ubergibt und erforderlichenf alls 
eine Fehlerbehandlungsprozedur auslost . Dies erfolgt far 
alle Services und Adapter generisch uber das gleiche 
Interface. Die FluEdef initionen FD sind spezifisch fur 
den BDoc-Typ in einera Steuerdatenspeicher (Repository) 
def iniert . 

Die von den Knotensystemen NS ubermittelten BDocs werden 
in einer Eingangsschlange IBQ gespeichert und von dort 
mittels eines Launchers LCH an die Bearbeitung durch die 
Flufisteuerung FC ubergeben. 

Die Kommunikation mit dem ERP-System OLTP-R/3 erfolgt 
uber einen entsprechenden Service R/3-S und zwei Adapter, 
namlich einen Outbound -Adapter OLTP-ADO und einen In- 
bound-Adapter OLTP-ADI . 

Ein Datenbankservice CDS (Consolidated Database Service) 
dient zur Speicherung von Daten in der konsolidierten Da- 
tenbank CD. Der Service CDS fuhrt keine Prufung auf Da- 
tenkonsistenz durch, wenn er Daten in die Datenbank CD 
schreibt. Derartige Checks mussen von den Knotensystemen 
durchgefuhrt werden, die Daten an das Zentralsystem uber- 
tragen. Zum Lesen der Datenbank CD verwenden die anderen 
Programmodule nicht den Datenbankservice CDS, sondern ein 
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Extractor-Modul EXT, das bei Bedarf aufgerufen werden 
kann. 

Ein Replikations -Service RPS dient dazu, Daten aus dem 
Zentralsystem CS im erf orderlichen Umfang in den Knoten- 
systemen NS zu replizieren. Er ubernimmt die bearbeiteten 
BDocs und bestimmt deren Adressaten, indem er sie aus ei- 
ner Lookup -Tabelle LUT (Lookup Table; nachfolgend wird 
nur noch die Kurzbezeichnung "LUT" verwendet) liest. Die 
LUT ist vorzugsweise eine sehr einfache zweispaltige Ta- 
belle, die den Primarschlusseln der BDocs jeweils die 
Schlussel (Site-ID) samtlicher Adressaten zuordnet . Sie 
ist indiziert und der Zugriff erfolgt mit logarithmischem 
Zeitverhalten, so dafi auch bei einer sehr umf angreichen 
LUT die Adressaten eines BDoc sehr schnell herausgelesen 
werden konnen. 

Wenn der Replikations -Service RPS feststellt, da£ infolge 
eines gegenwartig verarbeiteten BDocs die Adressatenzu- 
ordnung in der LUT geandert werden mufi, generiert er 
einen Realignment- Job fur ein Realignment -Modul RA. Wah- 
rend des Realignment verwendet das Realignment-Modul Re- 
plikationsregeln, die in einer Subskriptionstabelle ST 
(Subscription Table) abgelegt sind. AufSerdem ubergibt das 
Realignment-Modul RA mittels eines Extractor-Moduls Ande- 
rungsinformationen fur die Knotensysteme NS an die Flufc- 
steuerung, die sie in einer mit OBQ bezeichneten Aus- 
gangsschlange (Outbound Queue) zur Ubertragung an die 
Knotensysteme NS bereitstellt . 

Fur weitere Aufgaben konnen zusatzliche Services S1,S2 
implement iert sein. Da die erwahnten Programmodule spezi- 
fisch fur jeden BDoc-Typ definiert sind, symbolisieren 
die in Fig. 1 dargestellten Symbole (z.B. CDS, RPS) je- 
weils eine Serie der entsprechenden Module fur alle in 
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dem Datenbank-Netzwerksystem verwendeten BDoc-Typen. Auch 
das Symbol LUT represent iert vorzugsweise eine Mehrzahl 
von Lookup-Tabellen far unterschiedliche BDoc-Typen. 

Fur die Realisierung der Software in dem Zentralsystem CS 
wxrd vorzugsweise die Programmiersprache ABAP der SAP AG 
und deren R/3-Technologie verwendet . Sie ist transparent 
gegenuber unterschiedlichen Plattformen. Die Punktionen 
des Zentralsystems CS konnen auf mehrere Maschinen ver- 
teilt sein. Insbesondere konnen gesonderte Maschinen fiir 
die Datenbank und fur die Bearbeitung von Anf orderungen 
und die Systemverwaltung eingesetzt werden. 

In der Praxis ist es zweckmaSig, fiir die Zwecke der Sy- 
stemverwaltung eine Maschine einzusetzen, die als Admi- 
nxstrationsstation AS bezeichnet wird und beispielsweise 
unter Windows NT laufen kann. 

Ein Subskriptionsprufmodul SC (Subscription Checker) 
daent dazu, die LUT zu aktualisieren, wenn im Rahmen der 
Systemverwaltung an der Administrationsstation Systeman- 
derungen durchgefuhrt werden, die fur die Verteilung von 
Anderungsinformationen an die Adressaten von Bedeutung 
smd. Bevorzugt werden hi erzu - in Abhangigkeit von dem 
BDoc-Typ - zwei unterschiedliche Typen des Subskriptions- 
prufmoduls SC verwendet, wobei ein erster Typ unmittelbar 
Anderungen in einer LUT erzeugt, wahrend ein zweiter Typ 
solche Anderungen indirekt unter Verwendung des Realign- 
ment-Moduls bewirkt . 

Anhand von Pigur 2 wird die Struktur der BDocs naher er- 
lautert . 

Ein wesentliches Merkmal der fiir die Erfindung verwende- 
ten Replikationsobjekte (BDocs) ist, daS sie eine 
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logische Einheit bilden, die sicherstellt , daS die darin 
enthaltene Anderungs in format ion genau einmal transpor- 
tiert und verarbeitet wird. Die BDocs bilden also insbe- 
sondere eine Klammer, durch die sichergestellt wird, daS 
eine Datenubertragung zu einem Empf anger nur dann als 
erfolgreich angesehen wird, wenn sie vollstandig ist. 
Dies ist eine wichtige Voraussetzung fur die vollstandige 
und korrekte Replikation. Ohne diese Funktion der BDocs 
bestunde (beispielsweise bei Systemabsturzen) das Risiko, 
daS nur teilweise ubertragene Altdaten als vollstandig 
angesehen wurden. Dies wurde zu Replikationsf ehlern 
f uhren . 

Wie bereits erwahnt, ist ein BDoc ein Datencontainer, 
d.h. eine vorgegebene Struktur, in die unterschiedliche 
Daten eingefullt werden. Man muS zwischen unterschiedli- 
chen BDoc-Typen mit (in der Regel) unterschiedlichen 
Strukturen unterscheiden . Beispielsweise kann es BDoc-Ty- 
pen "Kunde" , "Produkt" etc. geben. Die einzelnen Exem- 
plare (Instanzen) der BDocs enthalten dann die Daten ei- 
nes bestimmten Kunden, Produktes etc. 

Vorzugsweise dienen die BDocs zur plattf ormubergreif enden 
und applikationsubergreifenden Ubertragung von Daten, 
d.h. sie erlauben die Datenubertrag zwischen Computersy- 
stemen, die unterschiedliche Plattf ormen (Betriebssystem 
und Datenbankverwaltungssystem) verwenden und in denen 
unterschiedliche Anwendungen implement iert sind. Urn dies 
zu gewahrleisten, mu£ die Struktur der beteiligten Daten - 
banksysteme in die BDocs abgebildet werden. Dies ge- 
schieht im Rahmen eines vorbereitenden Prozesses, der als 
BDoc -Model ling bezeichnet wird. Dabei werden entsprechend 
den Tabellen der Datenbanken Segmente der BDocs defi- 
niert. Die Segmente enthalten Links (in Form der entspre- 
chenden Schlussel) zu den entsprechenden Tabellen der 



WO 00/79408 




PCT/DEOO/01552 



18 



Datenbanken. Die BDocs enthalten also - gemafi einer be- 
vorzugten Ausfuhrungsf orm - physisch nicht die Daten 
selbst, sondern Links zu den in den Datenbanken abgespei- 
cherten Daten. Logisch bedeutet dies jedoch, daS sie 
einen Behalter zum Transport der Daten bilden. 

Beispielsweise enthalten bei einer Datenbank mit Tabellen 
"Angebot-Kopf" und "Angebot-Positionen" entsprechende 
BDocs des Typs "Order Header" einen Link zu der Daten- 
banktabelle "Angebot-Kopf" (die die Staramdaten, z.B. 
Identifikation des Kunden, Angebotsnumraer und das Datum 
eines Angebots enthalt) . Bin dem BDoc "Order Header" 
nachgeordnetes BDoc "Order- Item" enthalt einen Link zu 
der Datenbanktabelle "Angebot-Positionen" (in der die 
Einzelpositionen der Angebote abgespeichert sind) . In 
einfachen Fallen ist die Zuordnung zwischen Tabellen der 
beteiligten Datenbanken und Segmenten der BDocs wechsel- 
seitig eindeutig. Es gibt jedoch auch Falle, bei denen 
Tabelleninhalte auf mehrere BDocs aufgeteilt oder Inhalte 
mehrerer Tabellen in ein BDoc zusammengef afit werden. 

Insgesamt stellen die BDocs eine Zerlegung der gesamten 
(im oben definierten Sinne) offentlichen Datenmenge aller 
beteiligten Datenbanksysteme dar. Der Begriff "Zerlegung" 
ist dabei im mathematischen Sinne dahingehend zu verste- 
hen, daS alle offentlichen Daten der Datenbank genau ein- 
mal (uberlappungsfrei und vollstandig) in ein BDoc iiber- 
nommen werden . 

Aus dem Vorstehenden wird deutlich, dafi die Gesamtheit 
der BDocs ein Abbild der offentlichen Daten der an dem 
Datenbank-Netzwerksystem DBNS beteiligten Datenbank- 
systeme ist. Im Rahmen des BDoc -Model ling muS folglich 
die Struktur aller beteiligten Datenbanken auf semanti - 
scher Ebene berucksichtigt werden. AuSerdem sind im 
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Rahmen des BDoc -Model ling die Besonderheiten der Branche 
zu berucksichtigen, fur die das Datenbank-Netzwerk ver- 
wendet wird. In der Praxis geschieht dies dadurch, dafi 
seitens des Sof tware-Herstellers ein branchenabhangiges 
Basis -Modelling geliefert wird, das als "Template" be- 
zeichnet wird. Hierauf aufbauend erfolgt eine anwender- 
spezif ische Anpassung im Rahmen der Implement ierung des 
Systems bei einem bestimmten Unternehmen. 

In Figur 2 zeigt der obere Teil die Struktur der Defini- 
tion des BDoc-Typs. Die Struktur des BDocs selbst ist im 
unteren Teil dargestellt. Beide Strukturen sind in dem 
Repository des Zentral systems CS abgespeichert . 

Das BDoc besteht aus dem BDoc -Kopf (Header) BDoc-H und dem 
BDoc-Korper (Body) BDoc-B. Der BDoc-Header BDoc-H enthalt 
Steue rungs informationen wie beispielsweise den Typ 
("Kunde", "Auftrag" ...) des BDocs, dessen Absender 
(Knotensystem NS) und eine Zeitmarkierung (Time Stamp) . 
Aus Performance -Griinden ist es vorteilhaft, wenn er au- 
fierdem ein Duplikat des Primarschlussels enthalt. 

Die Daten sind in dem BDoc-Korper BDoc-B enthalten. Durch 
ein Flag im Root -Segment wird angezeigt, welcher Daten - 
bankoperation (Update, Insert oder Delete) die in dem 
BDoc codierte Anderungs information entspricht . Ein Daten- 
Rekord (Data Record) DR enthalt die eigent lichen Daten. 
Die Struktur ist in der Definition des zugehorigen Daten- 
segmentes (Data Segment) DS definiert. Die Segmente bil- 
den eine Art Tabellenansicht der tatsachlichen physischen 
Tabellen. Optional enthalt das BDoc auch ein Fehlerseg- 
ment ES (Error Segment) mit einem oder mehreren Fehler- 
Rekords ER (Error Record) . 
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Die Datenbereiche haben eine festgelegte Lange. sie be- 
stehen aus einem Sohlussel und Datenf eldern . Wenn sie 
eine Loschinf ormation enthalten, enthalt nur das Schlus- 
selfeld gultige Daten. Wenn sie "insert"- oder "update"- 
informationen enthalten, enthalten entweder alle Pelder 
gultige Daten oder unveranderte Felder enthalten einen 
Voreinstellungswert (beispielsweise 0.0). Um anzuzeigen 
ob ein Feld gefullt oder unbenutzt ist, werden sogenannte 
"Sende-Bits" benutzt. Primarschlussel und Felder, die bei 
Replikation und Realignment beriicksichtigt werden mussen, 
werden imrner gesendet (unabhangig davon, ob sie geandert 
wurden) . Sende-Bits werden nur gesetzt, wenn der Wert 
tatsachlich geandert wurde. 

Die Definition des BDoc-Typs, also die Information uber 
die fur den jeweiligen BDoc-Typ spezifische Struktur aus 
hierarchisch geordneten Elementen ist in der BDoc-Typ- 
Definition BDTD enthalten, die aus einer BDoc-Korper- 
Definition BDoc-BD und BDoc-Segment-Def initionen BDoc-SD 
besteht. Die BDoc-K6rper-Def inition BDoc-BD enthalt genau 
em Root-Segment, das nur einen einzigen Daten-Rekord 
enthalt. Diese Bedingung mufi eingehalten werden, um 
sicherzustellen, daS die in dem BDoc enthaltenen Informa- 
tionen individuell an die jeweiligen Knotensysteme uber- 
nuttelt oder in anderer Weise bearbeitet werden konnen. 
Beispielsweise darf in einem BDoc des Typs -Kunde" nur 
Informationen uber einen einzigen Kunden gespeichert 
sein, damit die Kundeninf ormation individuell und gezielt 
fur jeden einzelnen Kunden den entsprechenden Knoten- 
systemen zugeleitet werden kann. 

Wahrend die Segmente in der BDoc -Typ-Def inition BDTD 
hierarchisch strukturiert sind, gibt es bei der physi- 
schen Wiedergabe der BDocs selbst keine derartige Hierar- 
chy. Die hierarchische Abhangigkeit ist in den BDocs 
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dadurch enthalten, daS die Daten-Rekords DR abhangiger 
Segmente den Schlussel ihrer ubergeordneten Daten-Rekords 
enthalten. 

Fur die Performance des Systems ist wichtig, dafi die 
BDocs logisch nur die jeweils notwendige Ande rungs infor- 
mation ubermitteln. Dies wird auch als "Netto-Feld-Uber- 
tragung" bezeichnet. Sie enthalten also nur im Falle ei- 
nes Insert den kompletten Datensatz der jeweiligen In- 
stanz des jeweiligen BDoc-Typs (also z.B. alle Daten zu 
einem Auf trag) . Im Falle eines Update enthalten sie aufier 
der Identif ikation ihres Typs und der BDoc-Instanz - lo- 
gisch gesehen - nur den Inhalt des geanderten Datenfeldes 
(also beispielsweise einer geanderten Strafienadresse ei- 
nes Kunden. Im Falle eines Delete genugt die Ubermittlung 
der erforderlichen Identif ikationsschlussel . 

Die nachfolgend erlauterten Ablauf diagramme beziehen sich 
auf das Beispiel eines CRM-Systems. Dabei wird das Zen- 
tralsystem CS auch als "CRM-Server" bezeichnet . 

Figur 3 betrif ft die Behandlung von Anderungsinformatio- 
nen, die von den Knotensystemen NS ausgehen, d.h. 
zunachst in deren Anwendungsprogramm AS vorgenommen wer- 
den ("Upload") . Dieser Programmteil wird deshalb auch als 
"Application Modification Handling" bezeichnet. Er ist 
Bestandteil des Transaction Layer TL. 

Nach dem Start des Application Modification Handling 
(Schritt 301) werden in dem Schritt 302 die von dem 
Anwendungsprogramm AS geanderten Daten, die zur 
Speicherung in der lokalen Datenbank LD vorgesehen sind, 
von dem Transaction Layer TL ubernommen. Danach wird in 
dem gleichen Commit -Zyklus in dem Schritt 3 03 die in dem 
geanderten Datensatz enthaltene Neuinf ormation (Delta- 
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Information) bestimmt und in dem Schritt 304 als 
Transferformat ein BDoc generiert, das - wie beschrieben 
- einen eindeutigen Schlussel und die geanderte 
Information enthalt. 

Die nachfolgenden Schritte 305 bis 311 werden in dem 
gleichen Commit -Zyklus abgearbeitet . Sie bilden eine 
Transaktion in dem Sinn, da£ sie zwingend vollstandig 
ausgefuhrt werden miissen, d.h. daS jede Teiloperation der 
Transaktion nur ausgefuhrt wird, wenn auch alle anderen 
Teiloperationen ausgefuhrt wurden. 

Im vorliegenden Fall bezieht sich die Transaktion auf die 
Operationen 306 "Delta- Information in einem BDoc an das 
Zentralsystem versenden" und 310 "Delta-Information in 
der lokalen Datenbank LD abspeichern" . Durch die Program- 
mierung als Transaktion wird sichergestellt , dafl diese 
Operationen nur ausgefuhrt werden, wenn die Ausfuhrung 
beider Operationen sichergestellt ist. 

im AnschluS an den Schritt 306 erfolgt in dem Schritt 307 
eine Abfrage, ob das betreffende Knotensystem NS gerade 
mit dem Zentralsystem CS verbunden (online) ist. Bei ei- 
nem positiven Ergebnis dieser Abfrage wird unmittelbar 
ein Remote Call an die Inbound Queue IBQ des Zentralsy- 
stems CS ubermittelt. Das zu ubermittelnde BDoc bildet 
einen Anhang des Remote Call. 

In der Regel wird keine Online -Verbindung mit dem Zen- 
tralsystem CS bestehen. In diesen Fallen fuhrt das nega- 
tive Ergebnis der Abfrage 307 dazu, dafi in dem Schritt 
3 08 ein Remote Call in eine Ausgangsschlange gestellt 
wird, die in der lokalen Datenbank LD des Knotensystems 
NS abgespeichert wird. 
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Fur diese Queue gelten ebenso wie fur alle anderen Queues 
folgende Bedingungen: 

- Es ist sichergestellt, dafi jeder Aufruf der Schlange 
seinen Etnpf anger erreicht, anderenfalls wird ein Feh- 
lersignal erzeugt (Guaranteed Delivery) . 

Die Auf rufe der Schlange werden in der vorgegebenen 
Reihenfolge bearbeitet (In Order Processing) 

Jeder Aufruf wird genau einmal ausgefuhrt (Exactly 
Once) 

In dem Schritt 310 werden die Anderungsinf ormationen in 
die lokale Datenbank LD eingearbeitet . Dabei lost der 
Transaction Layer TL die BDocs in Tabellen auf, wobei 
alle Datensatze aller zugehdrigen Tabellen in einem 
Commit -Zyklus bearbeitet werden. Neuanlagen werden mit- 
tels SQL-Statement in der Datenbank angelegt . Anderungen 
werden netto (ebenfalls mittels SQL- Statement ) eingear- 
beitet . 

Figur 4 zeigt ein Ablauf schema des Sof twaremoduls, das 
dazu dient, die fur den Datenaustausch erf orderliche Ver- 
bindung zwischen den beteiligten Computersystemen herzu- 
stellen, auf rechtzuerhalten und nach Erledigung des er- 
forderlichen Datenaustausches zu beenden. Dieses Modul 
wird als ConTrans Manager CTM bezeichnet und ist in Figur 
1 der Ubersichtlichkeit halber nicht dargestellt. Es ist 
so angelegt, dafi es vollautomatisch f unktioniert , d.h. 
nach Aufruf des CTM ist keine Aktion des Benutzers mehr 
erf orderlich . 

Nach dem Start 401 des CTM wird in Schritt 402 ein 
Connection Service aufgerufen, durch den in dem Schritt 
403 eine Verbindung mit dem Zentralsystem CS hergestellt 



WO 00/79408 




PCT/DE0O/015S2 



24 



wird. Dies umfaEt beispielsweise die Wahl der Telefonnum- 
mer, IP-Adresse, PaSwort etc. und entspricht ublicher 
Technik. AnschlieSend wird in Schritt 404 ein CRM- Trans- 
fer-Service aufgerufen, der dafur sorgt, dafi die in der 
Ausgangsschlange des Transaction Layers TL des entspre- 
chenden Knotensystems stehenden BDocs mittels Remote Call 
ubermittelt werden. Solange solche Remote Calls existie- 
ren, werden sie aufgrund der Abfrage 405 in Schritt 406 
nacheinander ubermittelt. Wenn keine weiteren Remote 
Calls mehr vorhanden sind, wird die Abfrage 405 negativ 
beantwortet und der Ablauf geht zu der Abfrage 407 uber, 
ob auf der Seite des Zentralsystems Daten fur das ent- 
sprechende Knotensystem bereitstehen. Solange dies bejaht 
wird, werden sie in dem Schritt 4 08 an das Knotensystem 
ubertragen . 

Durch die Abfrage 409 "Verbindung verloren?" wird sicher- 
gestellt, dafi im positiven Fall die Kontrolle an den 
Schritt 402 ubergeht, der eine neue Verbindung mittels 
des Connection Service 402 herstellt. Im negativen Pall 
wird durch die Abfrage 410 "Session beendet?" festge- 
atellt. ob noch andere Transfer-Services, die in dem Zen- 
tralsystem CS implement iert sein konnen (wie beispiels- 
weise die Dbermittlung von E-Mails) , auf zurufen sind. 
Falls dies der Pall ist und demzufolge die Session noch 
nxcht beendet ist, wird in dem Schritt 411 der nachste 
Transfer- Service aufgerufen, sonst wird der Ablauf been- 
det (Schritt 412) . 

Die Verarbeitung der BDocs in dem Zentralsystem CS er- 
folgt mittels der FluEsteuerung PC. Ein Launcher-Process 
arbeitet die Eingangsschlange IBQ ab und startet fflr je- 
des empfangene BDoc einen Flow. Fur jeden BDoc-Typ ist in 
den FluSdefinitionen FD ein Graph definiert, durch den 
der Durchlauf der BDocs durch alle definierten Services 
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kontrolliert wird. Dies geschieht vollkommen generisch. 
Die konkrete Bearbeitung hangt von den definierten Servi- 
ces ab, wobei die Services die BDocs nicht nur transpor- 
tieren, sondern auch deren Inhalt andern, beispielsweise 
zusatzliche Felder erganzen oder vorhandene Feldinhalte 
entfernen konnen. Ein Beispiel ist das Hinzufugen system- 
ubergreif ender Schlussel bei der semantischen Integration 
unterschiedlicher Datenbanksysteme, die in der euro- 
paischen Patentanmeldung 99120009.8 n Integriertes Daten- 
bank-Verbundsystem" der gleichen Anmelderin beschrieben 
wird. Auf diese Anmeldung wird in dem Sinn Bezug genom- 
men, daE ihr Inhalt in vol 1 em Umfang zur Erganzung des 
Inhalt s der vorliegenden Anmeldung he range zogen we r den 
soil. 

Die allgemeinen Merkmale der FluSsteuerung FC sind in Fi- 
gur 5 dargestellt. Wenn nach dem Start 501 des Flusses in 
dem Schritt 502 ein BDoc an die FluSsteuerung zur Bear- 
beitung ubergeben wird, erfolgt der weitere FluS auf Ba- 
sis eines Graphen, der in dem Schritt 503 von den abge- 
speicherten Flufcdef initionen FD importiert wird. GemaS 
diesem Graphen werden die erf orderlichen Services der 
Flufidef inition abgearbeitet . Fur gebrauchliche BDoc-Typen 
(z.B. Kunde, Auftrag) durchlauft der Flu£ beispielsweise 
unter anderem f olgende Services : 

a) Einen Service R/3-S, urn die Anderungsinf ormationen 
auch dem ERP- System des Unternehmens zuganglich zu ma- 
chen (falls fur dieses System relevant, anderenfalls 
ist der R/3 -Service in dem FluS des entsprechenden 
BDoc-Typs nicht definiert) . 

b) Einen Service CDS , urn die Anderungsinf ormat ion in der 
konsolidierten Datenbank CD persistent zu machen. 
Hierzu lost der Datenbankservice CDS die BDocs in 
Tabellen auf und bearbeitet alle Datensatze aller 
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zugeh6rigen Tabellen in einem Commit - Zyklus . Neuanla- 
gen (insert) werden per SQL-Statement in der Datenbank 
angelegt. Updates werden (ebenfalls mittels SQL 
Statement) netto eingearbeitet . 

c) Einen Replikations -Service RPS, um die fur die Ande- 
rungsinformation zustandigen Knotensysteme NS in eine 
Adressatenliste (Recipient List) einzutragen. 

Die Abarbeitung samtlicher in dem importierten Graphen 
defmierten Services des Flow wird durch eine Schleife 
sichergestellt, die eine Abfrage 504 "FluS beendet?" und 
exnen Schritt 505 umfaEt, durch den im Falle einer nega- 
tiven Antwort auf die Abfrage der nachste Service aufge- 
rufen wird. 

Wenn alle Services abgearbeitet sind, erfolgt in dem 
Schritt 506 (als abschlieSender Schritt jedes von der 
FluSsteuerung FC gesteuerten Flusses) die in Figur 5 als 
"Exploding into the field" bezeichnete Verteilung der An- 
derungsinformation an die Knotensysteme NS. Dabei ruft 
die FluSsteuerung mittels eines Remote Function Call die 
Adressaten anhand der Adressatenliste. Dies bewirkt im 
Normalfall (namlich wenn gerade keine Online -Verbindung 
zu dem gerufen Knotensystem besteht) ein Queuen der Calls 
m den Outbound-Queues OBQ der einzelnen Knotensysteme 
Falls eine Online-Verbindung besteht, kann der Aufruf un- 
mattelbar weitergeleitet werden. Im Fehlerfall wird auf 
einen Fehlerbehandlungsservice verzweigt, um definierte 
Fehlerbehandlungsaktionen einzuleiten . 

Nachfolgend werden anhand der Figuren 6 bis 15 wesentli- 
che Besonderheiten im Zusammenhang mit der selektiven 
Ubertragung der Anderungsinformationen von dem Zentral- 
system CS an die Knotensysteme NS erlautert. Es wird der 



WO 00/79408 




PCT/DEOO/01552 



Ablauf von Programmodulen beschrieben, die gemalS bevor- 
zugter Ausfuhrungsformen der Erfindung verwendet we r den, 
urn sicherzustellen, dafi die Anderungsinf ormationen auch 
bei standigen dynamischen Anderungen der Daten in dem 
Da t enbank - Ne t z we rk system DBNS mit relativ geringem Re- 
chenaufwand und gruter Performance an die jeweils rich- 
tigen Adressaten unter den Knotensystemen verteilt wer- 
den. Zugleich soil das System sowohl hinsichtlich der An- 
passung an die Bedurfnisse unterschiedlichster Benutzer- 
gruppen als auch hinsichtlich der spateren Anpassung be- 
reits installierter Systeme an sich andernde Anforderun- 
gen eine moglichst gro£e Flexibilitat gewahrleisten . 

Dabei spielen folgende Funktionen eine wesentliche Rolle: 

Replikation durch einen Replikat ions -Service RPS 

Realignment durch ein Realignment -Modul RA 

Extraktion durch einen Extrakt- Service EXT 

Subskriptions-Pruf ung durch ein Subskriptionspriif modul 
SC. 

Bei den in den Figuren 6, 7 und 8 dargestellten Programm- 
ablauf diagrammen, die die Replikation anhand von drei un- 
terschiedlichen Grundtypen beschreiben, wird davon ausge- 
gangen, daS ein bestimmter BDoc-Typ zur Bearbeitung an- 
steht. Wie bereits erlautert, werden die BDoc-Typen, die 
in einem bestimmten Dat enbank - Netz we rksys tern DBNS verwen- 
det werden, bei der Einrichtung des Systems im Rahmen des 
BDoc-Modelling def iniert . Die Replikation mittels eines 
Replikations- Services RPS ist spezifisch fur den BDoc- 
Typ, d.h. fur jeden BDoc-Typ ist ein bestimmter Replika- 
tions-Service def iniert, wobei selbstverstandlich ein 
gleicher Replikations-Service fur mehrere BDoc-Typen ver- 
wendet werden kann. Bei der Einrichtung des Datenbank- 
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Netzwerksystems DBNS werden die erf orderlichen Replika- 
tions-Services mittels einer generischen Engine und in 
einem Repository gespeicherter Steuerdaten generiert. 
Jeder Replikations -Service beginnt damit, daS die FluS- 
steuerung ein BDoc ubergibt und den Service aufruft. 

Zum besseren Verstandnis wird in den nachf olgenden Erlau- 
terungen beispielhaft auf ein CRM-System Bezug genommen, 
bei detn die AuSendienstmitarbeiter jeweils fur ein be- 
st immtes raumliches Vertriebsgebiet zustandig sind. In 
den Vertriebsgebieten sind jeweils bestimmte Kunden, die 

von den AuSendienstmitarbeitern betreut werden, lokali- 
siert . 

Wenn sich der Name eines Ansprechpartners bei einem Kun- 
den andert, mu£ die damit verbundene Anderungsinformation 
als Update an alle Aufiendienstmitarbeiter des jeweiligen 
Gebietes ubermittelt werden. Dies geschieht im Rahmen der 
Replikation. 

Bei manchen Anderungsinf ormationen geniigt es jedoch 
nicht, sie nur gemaS der aktuellen LUT an die entspre- 
chenden Adressaten weiterzuleiten. Vielmehr fuhrt die An^ 
derungsinformation in vielen Fallen dazu, daS auch die 
LUT geandert werden muS. Hierzu gehSren alle Anderungsin- 
f ormationen der Typen Insert und Delete, well die Einfii- 
gung neuer Replikationsobjekt-Instanzen (beispielsweise 
eines neuen Kunden oder eines neuen Auftrags) jeweils zu 
einer entsprechenden Aktualisierung der Lookup- Tabe lie 
(Einfugen der Adressaten fur die neue Replikationsobjekt- 
Instanz, Loschen der Zuordnungen fur die nicht mehr exi- 
stierende Replikationsobjekt-Instanz) fiihren muS. Auch 
Updates konnen zu einer Anpassung der LUT fahren. Ein 
Beispiel ist der Umzug eines Kunden aus einem Verkaufsge- 
biet A in ein Verkauf sgebiet B. Er fvihrt zunachst zu 
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einer Anderungen im Feld "Adresse" des BDoc "Kunde". Im 
Rahmen der Erfindung wird ein derartiges Update bei der 
Verteilung der Anderungsdaten an die Adressaten dadurch 
berucksichtigt , daS ein entsprechendes Datenfeld (bei- 
spielsweise ein Datenfeld, das die Postleitzahl der 
Kundenadresse enthalt) als "verteilungskritisches Feld" 
definiert wird. Eine Anderung in einem solchen Feld kann 
- wie noch naher erlautert wird - zu einer Anderungen der 
LOT fuhren. Die Aktualisierung der LUT ist Teil der 
Realignment -Funkt ion . 

Eine solche AdreiSanderung hat zur Folge, daS die Daten 
des Kunden an alle Knot ensyst erne des Vertriebsgebiets B 
ubermittelt und aus den Knotensystemen des bisherigen 
Vertriebsgebietes A geloscht werden mussen. Dies bedeutet 
eine Anderung der LOT. Wenn also ein BDoc des Typs 
"Kunde" bearbeitet wird, dessen Adrefifeld eine Anderung 
enthalt, mufi zunachst festgestellt werden, ob diese Ande- 
rung eines verteilungskritischen Feldes tatsachlich zu 
einer Anderung der Verteilung f iihrt . Im negativen Fall 
muS die Anderung alien Knotensystemen des bisherigen 
(unveranderten) Vertriebsgebietes A mitgeteilt werden. Im 
posit iven Fall muS sie alien Knotensystemen des neuen 
Vertriebsgebietes B mitgeteilt werden, wahrend gleichzei- 
tig eine Loschung in den Knotensystemen des alten Ver- 
triebsgebietes A erfolgt. 

Zur Einarbeitung dieser Anderungen sind Insert- und 
Delete-Operationen erf orderlich, die im Rahmen des 
Realignment veranlafit werden. Vorzugsweise werden sie 
aber nicht sofort ausgef iihrt, sondern es wird ein 
Extract- Job generiert, der von dem Extract or -Modul EXT 
unabhangig und asynchron abgearbeitet wird. Das Extrac- 
tor-Modul erzeugt BDocs, die zur Durchfuhrung einer 
Insert- oder Delete-Operation an eine der an dem Daten- 
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bank-Netzwerksystem DBNS beteiligten Datenbanken iibermit- 
telt werden konnen. 

SchlieSlich sind Systemanderungen zu berucksichtigen, die 
von dem Systemverwalter uber die Administrationsstation 
AS vorgenommen werden. Dies gilt insbesondere fur Um- 
strukturierungen des Datenbank-Netzwerksystems, die sich 
beispielsweise aus der Einfugung zusatzlicher Knoten- 
systeme oder aus sonstigen Anderungen der fur die Vertei- 
lung von Anderungsinformationen an die Adressaten gillti- 
gen Regeln (die zu einer Anderung der Subskriptions- 
tabelle fuhren) ergeben. Derartige Anderungen werden mit- 
tels des Subskriptionsprufmoduls SC in das System einge- 
arbeitet . 

Figur 6 zeigt den Programraablauf eines Replikations- 
Service-Typs, der als Bulk-Replikation bezeichnet wird. 
Er wird fur BDocs verwendet, die abhangig von ihrem Typ 
(aber unabhangig von der jeweiligen BDoc-Instanz und 
ihrem Dateninhalt) an bestimmte Adressaten iibertragen 
werden. Bin typisches Beispiel sind Stammdaten, die jedem 
AuSendienstmitarbeiter eines Unternehtnens zur Verfugung 
stehen mussen, beispielsweise uber die Produkte des Un- 
ternehtnens (BDoc-Typ "Produkt-Stammdaten") . 

Solche Bulk-BDocs konnen im Rahmen der Erfindung einfach 
und mit einem Minimum an Rechenzeit (also sehr schnell) 
verarbeitet werden. Bin typischer Algorithms ist in Fi- 
gur 6 dargestellt. 

Nach dem Start 601 und der Ubergabe des BDoc 602 durch 
die FluEsteuerung werden in dem Schritt 603 die aktuellen 
Adressaten (Current Responsibles) fur den BDoc-Typ aus 
der LUT herausgelesen. Hierzu kann eine Filterf unktion 
der Datenbank-Software verwendet werden. Die LUT ordnet 
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den Primarschlusseln der BDoc-Typen jeweils die Schlussel 
(Site- ID) samtlicher Adressaten zu, die in der Subskrip- 
tionstabelle als Subskribenten dieses BDoc-Typs verzeich- 
net sind. Vorzugsweise wird fur mehrere oder alle Bulk- 
Replikationen (also fur mehrere oder alle BDoc-Typen, die 
im Wege der Bulk-Replikation an die Adressaten verteilt 
werden) eine gemeinsame LUT angelegt, die in Figur 6 mit 
B-LUT (Bulk LUT) bezeichnet ist . 

Im nachsten Schritt 604 der Bulk-Replikation erfolgt eine 
Abfrage, ob der Absender des BDoc zu den Adressaten der 
darin enthaltenen Anderungsinf ormation gehort . Falls dies 
bejaht wird, wird in dem Schritt 605 im Kopf BDoc-H des 
BDoc die Adressatenliste eingetragen. Dies geschieht vor- 
zugsweise physisch durch Verweis auf einen die Adressa- 
tenliste def inierenden Datensatz in einer Adressenliste 
AL, die die Schlussel (Site-ID) der Adressaten enthalt. 

Es besteht auch die Moglichkeit, daS der Autor einer An- 
derungsinf ormation (also das Knotensystem, in dem die in 
dem BDoc enthaltene Anderungsinf ormation erfafit wurde) 
nicht zu deren Adressaten gehort und deswegen die Abfrage 
604 zu einem negativen Ergebnis f uhrt . Diese Moglichkeit 
hangt damit zusammen, daS das System eine Datenverf lech- 
tung erlauben soil. Beispielsweise kann es vorkommen, daS 
ein Aufcendienstmitarbeiter aus einem Verkauf sgebiet A 
vertretungsweise fur einen Kollegen aus einem Verkauf sge- 
biet B Anderungen in das System eingibt und dazu seinen 
eigenen Laptop benutzt, der dem Verkauf sgebiet A zugeord- 
net ist. 

In einem solchen Fall wird vor der Erstellung der Adres- 
satenliste (Schritt 605) in dem Schritt 606 ein Extract- 
Job in eine Extractor- Queue eingestellt, der zum L6schen 
der entsprechenden Empf anger information fuhrt, wie weiter 
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unten noch naher erlautert wird. Dies ist notig, um zu 
verhindem, daS der geanderte Datensatz in dem zu dem 
Verkaufsgebiet A gehdrenden Knotensystem erhalten bleibt 
obwohl er dort nicht nur unndtig ist, sondem - weil er ' 
nicht gepflegt wird - rasch veraltet und zu Dateninkonsi- 
stenzen f iihrt . 

Die in Figur 7 dargestellte intelligente Replikation und 
dxe xn Figur 8 dargestellte abhangige Replikation lassen 
sich unter dem Oberbegriff "objektweise Replikation" zu- 
sammenfassen. Damit werden Falle bezeichnet, bei denen 
die Verteilung an die Adressaten nicht nur von dem BDoc- 
Typ, sondem von der einzelnen BDoc-Instanz, also dem je- 
weiligen Datenobjekt, abhangig ist. Dabei lassen sich 
folgende Falle unterscheiden: 

- Der Inhalt eines verteilungskritischen Feldes kann 
dazu fuhren, daS die LUT fur dieses BDoc und mogli- 
cherweise auch fur mit diesem verknupfte BDocs gean- 
dert werden muS. Dies geschieht durch eine "intelli- 
gente Replikation" , bei der ein Realignment Job 
generiert wird. 

- Die Replikation muS zwar auf der Ebene der BDoc-In- 
stanz (objektweise) erfolgen, jedoch in Abhangigkeit 
von einem iibergeordneten Objekt. Eine solche Abhangig- 
keit der Replikationsobjekte entspricht in der Regel 
einer entsprechenden Abhangigkeit von Tabellen der an 
dem Datenbank-Netzwerksystem beteiligten Datenbanken. 
Ein typisches Beispiel sind Auftrage, die itnmer mit 
einem Kunden verknupft sind (es gibt nur Auftrage ei- 
nes Kunden) . Deswegen mOssen alle Auftrage eines Kun- 
den genau so an die Adressaten verteilt werden, wie 
die Kundendaten selbst. Der BDoc-Typ "Auftrag" wird 
jedoch fur viele Auftrage unterschiedlicher Kunden 
verwendet. Jede Instanz dieses Typs enthalt ein Feld 
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zur Identif ikation (GUID) des Kunden, das anzeigt, zu 
welchem ubergeordneten Replikationsobjekt eine Abhan- 
gigkeit besteht und das fur die Verteilung an die 
Adressaten benutzt wird. 

Ein Algorithmus fur die intelligente Replikation ist in 
Figur 7 dargestellt . Nach dem Start 701 des Service und 
der Ubergabe des BDoc (Feld 702) erfolgt eine Abfrage des 
(in einem Feld des BDoc definierten) Typs der Datenbank- 
operation. 

Falls es sich urn ein Insert oder Delete handelt, wird in 
dem Schritt 704 ein Realignment- Job generiert . Dies be- 
deutet nicht, daS sofort ein Realignment durchgefuhrt 
wird. Vielmehr wird nur ein Befehl erzeugt, der in eine 
Realignment Queue RAQ eingestellt und asynchron zu einem 
beliebigen Zeitpunkt verarbeitet wird. 

Falls die in dem BDoc codierte Datenbankoperation ein 
Update ist, erfolgt eine Abfrage 706, ob ein verteilungs- 
kritisches Feld geandert wurde . Im positiven Fall wird 
wiederum in dem Schritt 704 ein Realignment- Job gene- 
riert . 

Im Anschlufi an die Erzeugung eines Realignment- Jobs er- 
folgt stets eine Abfrage 707, ob in dem BDoc ein Link zu 
anderen BDocs (Replikationsobjekten) existiert. Im posi- 
tiven Fall wird in dem Schritt 708 auch fur das ver- 
kniipfte Objekt ein Realignment- Job generiert. Dies be- 
zieht sich beispielsweise auf Falle, bei denen der Kunde 
seinen Sitz in einem Vertriebsgebiet A hat, jedoch einem 
Konzern angehort, dessen Hauptquartier in einem Ver- 
triebsgebiet B liegt. Diese Information wird durch einen 
Link in dem entsprechenden BDoc des Kunden codiert und in 
dem Schritt 708 verwendet, urn sicherzustellen, daS nicht 
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nur die Aufiendienstmitarbeiter in dem Gebiet A, sondern 
auch die Aufiendienstmitarbeiter in dem Gebiet B Ande- 
rungsinformationen erhalten, die wegen des Sitzes der 
Muttergesellschaft fur sie wichtig sind. 

In jedem Pall wird der Algorithmus in gleicher Weise wie 
bei Figur 6 dadurch fortgesetzt, daS aus der LUT die ak- 
tuell giiltigen Adressaten (ohne Berucksichtigung der An- 
derungen, die aus der Bearbeitung des aktuellen BDoc mog- 
licherweise resultieren) herausgelesen und auf dieser Ba- 
sis in dem Schritt 710 die Adressatenliste im Kopf des 
BDoc erstellt wird. 

Die Adressatenliste enthalt in manchen Fallen keine Ein- 
trage. Wenn sich beispielsweise die in dem BDoc, das den 
in Fig. 7 dargestellten Algorithmus durchlauft, codierten 
Daten auf einen neuen Kunden beziehen (allgemein bei je- 
dem Insert) enthalt die O-LUT fur das neue Replikati- 
onsobjekt keine Eintrage . Die Verteilung an die fur den 
neuen Kunden zustandigen Knotensysteme erfolgt erst im 
Rahmen des Realignment. 

Da die intelligente Replikation auf der Ebene der BDoc- 
Instanzen stattfindet, also fur jede Instanz Zuordnungen 
aller Adressaten in der LUT vorhanden sein mussen, erge- 
ben sich (beispielsweise fur eine grofie Zahl von Kunden 
eines Versandhauses) sehr umfangreiche LUTs . Vorzugsweise 
werden die Adressaten-Zuordnungen der Instanzen eines 
BDoc-Typs zu einer gemeinsamen LUT zusammengef aSt , die 
als O-LUT (Objekt-LUT) bezeichnet wird. 

Besonders bevorzugt ist in dem Zentralsystem CS eine 
B-LUT (Adress- Zuordnungen der per Bulk-Replikation ver- 
teilten BDoc-Typen) und eine Vielzahl von 0-LUTs vorhan- 
den, die jeweils fur jede einzelne Instanz eines mittels 
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intelligenter Replikation verteilten BDoc-Typs die Zuord- 
nungen der Adressaten (Site-IDs) enthalt . 

Der Schritt 711 markiert das Ende des Service (Ubergabe 
des BDoc an die FluiSsteuerung FC) . 

Figur 8 zeigt den als "Dependent Replication" bezeichne- 
ten Ablauf eines Service zur Replikation eines BDocs, 
dessen Weiterleitung an die Adressaten von einem uberge- 
ordneten BDoc (in Figur 8 als RO = Replication Object be- 
zeichnet) abhangig ist . In diesem Fall werden nach dem 
Start 801 des Services und der Ubernahme des BDoc 
(Schritt 802) in dem Schritt 803 aus einer Lookup -Tabe lie 
die Adressaten des ubergeordneten BDoc (also z.B. des 
Kunden, fur den ein Auftrag durchgefuhrt wird) aus der 
LUT abgefragt. Die weiteren Schritte 804 bis 808 entspre- 
chen den Schritten 604 bis 608 der Bulk-Replikation 
(Figur 6) . 

Es wird deutlich, daS die abhangige Replikation ein ein- 
facher Algorithmus ist, der sehr schnell ausgefuhrt wer- 
den kann. Dies ist fur die Performance des Gesamt systems 
von erheblicher Bedeutung, weil in der Praxis die Anzahl 
abhangiger Replikationsobjekte in der Regel sehr grofc 
ist. 

Die Figuren 9 bis 12 dienen zur Erlauterung der Funktio- 
nen, die von einem Realignment -Modul RA ausgefuhrt wer- 
den. Sie gliedern sich in zwei Teilauf gaben, namlich: 

- Die Aktualisierung der LUTs auf Basis von Datenande- 
rungen in einer der lokalen Datenbanken UD oder in der 
konsolidierten Datenbank CD und 

- die Veranlassung der aufgrund solcher Anderungen not- 
wendigen Insert- und Delete-Operationen. 
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Das Realignment wird asynchron zu einem beliebigen Zeit- 
punkt, der normalerweise von dem Systemverwalter festge- 
legt wird. im Batch-Verf ahren durchgef flhrt . Da das 
Realignment-Modul nicht von der FluSsteuerung FC kontrol- 
liert wird, wird es nicht als Service bezeichnet. Die 
asynchrone, von der Replikation unabhangige Durchfuhrung 
des Realignment ist von grofier Bedeutung im Hinblick auf 
die gleichmaEige Auslastung des Gesamt systems (Load 
Balancing) . Wenn beispielsweise das Realignment nachts 
durchgefuhrt wird, wird die Hauptnutzungszeit des Systems 
entlastet und dadurch die Performance verbessert. 

Die in der Realignment Queue stehenden Realignment- Jobs 
enthalten vorzugsweise nur den Primarschlussel des jewei- 
ligen BDocs (der die BDoc-Instanz, beispielsweise einen 
bestimmten Kunden, eindeutig identif iziert) und die Iden- 
tifikation des BDoc-Typs. Der Dateninhalt des BDocs wird 
bei Bedarf aufgrund des Primarschlussels aus der konsoli- 
dierten Datenbank CD abgefragt. Der Typ des BDocs ist be- 
stxmmend fur die Art der Zuordnung (Assignment) der Daten 
zu den Knot en. 

Die Figuren 9 und 10 zeigen den Programmablauf eines 
Realignment-Algorithmus mit Ausnahme der Funktion 
"Interlinkage", die anschlieSend anhand der Figuren 11 
und 12 erlautert wird. 

Nach dem Start 901 werden in einem Schritt 902 die in der 
Realignment Queue RAQ stehenden Jobs sequentiell von ei- 
nem Queue-Leser ubernommen. Durch die sequentielle Bear- 
beitung wird sichergestellt , dafi die Reihenfolge die 
gleiche ist, in der die Anderungsinf ormationen, die den 
Realignment-Jobs zugrundeliegen, in dem Zentralsystem CS 
verarbeitet worden sind. 
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Anschliefiend erfolgt in dem Schritt 903 eine Abfrage hin- 
sichtlich des Typs des Assignments, also der Art Zuord- 
nung zwischen dem BDoc in der Realignment Queue RAQ und 
den Knotensystemen NS. Diese Zuordnung ist von dem Typ 
des BDocs abhangig. In dem Repository ist hinterlegt, 
welcher Typ des Assignments fur die einzelnen BDoc-Typen 
zu verwenden ist. Es sind folgende Moglichkeiten zu un- 
terscheiden : 

a) Direct Assignment. 

Diese Zuordnung wird fur Falle benutzt , bei denen die 
Adressaten unmittelbar vom Dateninhalt eines Feldes 
des BDoc abhangig sind. Zur Ermittlung der Adressaten 
wird beispielsweise das Feld Verkauf sgebiet ("Area") 
abgefragt und nach des sen Inhalt we r den aufgrund der 
im Repository des CS abgelegten Subskriptionstabelle 
ST die Adressaten f estgelegt . 

b) Referential Assignment. 

Diese Art der Zuordnung wird in Fallen verwendet, bei 
denen die Adressaten primar aus einer bereits exi- 
stierenden LOT eines iibergeordneten Replikationsob- 
jektes abgelesen werden konnen, aber zusatzlich eine 
intelligente Abfrage auf Basis eines Dateninhaltes 
erforderlich ist. Ein Beispiel sind Auftrage, die im 
wesent lichen (wie weiter oben erlautert) in Abhan- 
gigkeit von den Kunden, fur die sie ausgefuhrt wer- 
den, an die Adressaten, die die jeweiligen Kunden be- 
treuen, verteilt werden. Wenn keine zusatzlichen Ver- 
teilungskriterien berucksichtigt werden mussen, er- 
folgt diese Verteilung als abhangige Replikation ge- 
malS Figur 8 . In diesen Fallen ist kein Realignment 
erforderlich und es steht kein Realignment- Job in der 
Realignment Queue an. 
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Es gibt aber Falle, bei denen zusatzliche Kriterien 
bei der Verteilung an die Adressaten berucksichtigt 
werden mussen. Dies gilt beispielsweise fur Netz- 
werke, bei denen die Knotensysteme NS von Architekten 
benutzt werden. Dabei kommt es haufig vor, daS ein 
Architekt ein bestimmtes Bauwerk (Auftrag) betreut, 
obwohl er nicht im Gebiet des Kunden (Bauherr) ansas- 
sig und deswegen nicht fur diesen zustandig ist. in 
diesem Fall mussen die Daten uber das Bauwerk nicht 
nur - als abhangige Replikation - an die im Ver- 
triebsgebiet des Kunden lokalisierten Knotensysteme, 
sondern (aufgrund einer intelligenten Abfrage eines 
bestimmten Feldes) auch an den fur dieses Bauwerk zu- 
standigen Architekten verteilt werden. 

c ) Interlinkage . 

Dieser Typ der Zuordnung wird im Zusammenhang mit den 
Figuren 11 und 12 erlautert. 

Im Falle eines direkten oder ref erentiellen Assignments 
verzweigt der Programmablauf zu den Schritten 904 bis 
912, die nacheinander (teilweise optional) ausgefuhrt 
werden . 

In dem Schritt 904 werden die Inhalte der verteilkriti- 
schen Felder des BDoc aus der konsolidierten Datenbank CD 
ubernommen. Die folgenden Schritte 905 und 906 sind op- 
tional in dem Sinn, daS abhangig von der Art der Zuord- 
nung und dem verarbeiteten BDoc mindestens einer der 
Schritte durchgefuhrt wird, wobei der Schritt 905 auch 
mehrfach durchgefuhrt werden kann. 

In dem Schritt 905 werden die neuen Adressaten (Current 
Responsibles) aus LUTs ubergeordneter Replikationsobjekte 
SRO-LUT (Lookup Table of Superior Replication Object) 
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abgefragt. Dies Jcann mehrfach erforderlich sein, wenn das 
bearbeitete BDoc Links zu mehreren ubergeordneten Objek- 
ten enthalt (beispielsweise ein Auftrag, der fur mehrere 
Kunden durchgefuhrt wird, z.B. ein Bauwerk fur eine Bau- 
herrengemeinschaf t ) . 

In dem Schritt 906 werden aufgrund direkter Zuordnung die 
neuen Adressaten berechnet . Dies geschieht durch Ver- 
gleich verteilungskritischer Felder des BDoc mit einer 
Subskriptionstabelle ST, die im Repository abgelegt ist . 
Im Falle eines Referential Assignment konnen beide 
Schritte 905 und 906 erforderlich sein. Im Falle eines 
BDoc mit direktem Assignment wird nur der Schritt 906 
ausgef uhrt . 

Die Subskriptionstabellen ST werden ihrerseits haufig ge- 
andert, sind also hochgradig dynamisch. Wenn beispiels- 
weise ein neuer AuSendienstmitarbeiter in einem Verkaufs- 
gebiet A eingesetzt wird, fuhrt der Systemverwalter eine 
Anderung dahingehend durch, da£ der Aufiendienstmitarbei- 
ter XY als neuer Subskribent fur die das Verkauf sgebiet A 
betreffenden Anderungen eingefugt wird. Die daraus resul- 
tierenden Anderungen der Subskriptionstabelle ST werden 
durch die Subskriptionsprufung (Figuren 14 und 15) bear- 
beitet . 

Die Schritte 907 bis 909 dienen dazu, die erf orderliche 
Aktualisierung der Lookup -Tabe lie des bearbeiteten BDocs 
durchzuf uhren . Soweit die Adressaten der Anderungs infor- 
mation unverandert bleiben, ist keine Anderung der LOT 
erforderlich. Deswegen werden zunachst in dem Schritt 907 
die "alten" Adressaten aus der LOT ausgelesen und in dem 
Schritt 908 wird ein Vergleich zwischen den aktuellen und 
den alten Adressaten durchgefuhrt, urn zusatzliche 
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("neue") Adressaten und nicht mehr aktuelle ( "Ex" ) Adres- 
saten zu bestimmen. 

Auf dieser Basis werden in dem Schritt 909 die fur die 
Aktualisierung der LUT erforderlichen Anderungen festge- 
legt . Das Update ist zu diesem Zeitpunkt aber noch nicht 
aktiv, d.h. die Anderungen werden noch nicht durchge- 
fuhrt, sondem lediglich (durch Setzen eines Flag) mar- 
kiert. Dies ist von erheblicher praktischer Bedeutung, 
insbesondere weil verhindert werden mu£, dafi in die Out- 
bound Queue OBQ Anderungen fur ein bestimmtes Knoten- 
system eingestellt werden, obwohl es die Grunddatenbef ul - 
lung des betreffenden Replikationsobjektes (Insert) noch 
nicht hat. Bezogen auf das diskutierte Beispiel muB also 
verhmdert werden, daS eine Anderung eines Ansprechpart - 
ners eines Kunden bereits zur Ubermittlung an einen be- 
stimmten Laptop bereitgestellt wird, bevor dieser Laptop 
die Kundendaten selbst enthalt. 

Die in Figur 10 dargestellten Schritte 910 und 911 dienen 
dazu, die erforderlichen Insert -Operationen bei den neuen 
Adressaten und Delete -Operationen bei den Ex -Adressaten 
zu veranlassen. Hierzu werden die erforderlichen Extract- 
Jobs (vgl. Figur 13) generiert und in die Extractor Queue 
EXQ eingestellt. Dies bezieht sich jeweils auf das gerade 
bearbeitete BDoc und eventuell hiervon abhangige BDocs. 

Die Erzeugung von Extract -Jobs auch fur BDocs, die von 
dem gerade bearbeiteten BDoc abhangig sind, ist notwen- 
dig, um sicher zu stellen, daS bei der Erstdatenbefullung 
ernes Knotensystems NS alle erforderlichen Inf ormationen 
ubermittelt werden. Wenn z.B. die Daten eines neuen Kun- 
den an die zustandigen AuSendienstmitarbeiter ubermittelt 
werden, miissen die neuen Adressaten nicht nur dessen Da- 
ten, sondem auch weitere Daten (beispielsweise iiber 
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Ansprechpartner, Auftrage fur den Kunden und dergleichen) 
erhalten. 

Durch die Insert -Operationen erhalten alle neuen Adressa- 
ten den gesamten Datensatz der gerade bearbeiteten BDoc- 
Instanz . Bei den Ex-Adressaten werden alle Daten dieser 
BDoc-Instanz geloscht . Damit ist die Voraussetzung ge- 
schaffen, dafi kunftige Datenanderungen dieses Replikati- 
onsobjektes auch an die neuen Adressaten ubermittelt wer- 
den konnen bzw. es muS vermieden werden, da£ sie an die 
Ex-Adressaten ubermittelt werden. Deswegen werden die 
neuen Adressaten und die Ex-Adressaten nun in die O-LUT 
ubemommen, d.h. die zuvor noch nicht durchgef uhrte 
Aktualisierung der O-LUT wird aktiviert. Dies geschieht 
vorzugsweise in dem gleichen Commit -Zyklus mit der Erzeu- 
gung der Extract - Jobs . 

Schliefilich werden in dem Schritt 912 im Falle von BDocs, 
die nach eigenen Regeln und zusatzlich abhangig von uber- 
geordneten Replikationsobjekten verteilt werden 
("abhangige intelligente BDocs") Folgeauf trage generiert 
und in die Realignment Queue eingestellt. Ein Beispiel 
sind Falle der erlauterten ref erentiellen Zuordnung. Wenn 
beispielsweise das gerade bearbeitete BDoc ein Auf trag 
ist, der im Falle des beschriebenen Architektensystems 
einen Link zu einem Architekten enthalt, wird fur diesen 
ein zusatzlicher Realignment- Job generiert. 

In einer weiteren Abfrage 913 wird f estgestellt , ob das 
bearbeitete BDoc zusatzlich uber Interlinkage repliziert 
werden mufi. Im positiven Fall findet in dem Schritt 914 
ein Interlinkage Realignment statt, das anhand der Figu- 
ren 11 und 12 naher erlautert wird. Nach Abschlufi des 
Interlinkage Realignment oder bei einer negativen Antwort 
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auf die vorausgehende Abfrage wird der Service beendet 
(915) . 

Mit der abhangigen Replikation gemaS Figur 8 kdnnen nur 
1:N-Beziehungen, wie beispielsweise zwischen einem Kunden 
und den fur diesen bearbeiteten Auftragen verarbeitet 
werden. In der Praxis sind jedoch auch Palle von N:N-Be- 
ziehungen haufig. Wenn beispielsweise bei dem oben er- 
wahnten Architektensystem ein Architekt fur ein Bauwerk 
eines "gebietsf remden" Kunden zustandig ist, der aufier- 
halb seines Tatigkeitsgebietes seinen Sitz hat, erhalt er 
im Wege des Referential Assignment zwar die Daten des 
Bauwerks (Auftrag) , nicht jedoch die des Kunden. Die Kun- 
dendaten erhalt er mittels eines in dem BDoc ••Auftrag" 
vorgesehenen Links zu dem Kunden. Dies ist ein 
Interlinkage zwischen unterschiedlichen BDoc-Typen 
(Auftrag-Kunde) . Haufig sind aber auch Links zwischen un- 
terschiedlichen Instanzen des gleichen BDoc-Typs vorhan- 
den, so beispielsweise urn Beziehungen zwischen verschie- 
denen Kunden, die sich auf die Verteilung von Ande- 
rungsinformationen auswirken, zu berucksichtigen. 

Derartige Aufgaben werden durch das als Interlinkage be- 
zeichnete Programmodul gelfist. Voraussetzung ist, daS bei 
der Einrichtung des Systems oder zu einem spateren Zeit- 
punkt entsprechende Links definiert wurden. Die Defi- 
nition von Links kann auch von der Anwendungssof tware AS 
der Knotensysteme NS erzeugt werden, beispielsweise wenn 
exn AuSendienstmitarbeiter eine im System bis jetzt noch 
nxcht berucksichtigte Beziehung zwischen Kunden fest- 
stellt. Auch solche Anderungsinformationen werden in 
BDocs codiert, in das Zentralsystem CS transportiert und 
dort rekursiv durchgearbeitet, um entsprechende Links zu 
generieren . 
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Alle Verknupfungen zwischen BDocs (des gleichen Typs oder 
unterschiedlicher Typen) sind vorzugsweise in der conso- 
lidierten Datenbank CS als sogenannte Interlinkage-Ta- 
belle gespeichert. In dieser Tabelle werden die Schlussel 
(GUIDs) aller miteinander verknupften Replikationsobjekte 
(vorzugsweise paarweise in einer zweispaltigen Tabelle) 
einander zugeordnet . Die BDocs enthalten die Information 
uber von ihnen ausgehende Verknupfungen vorzugsweise 
durch Verweis auf eine solche Interlinkage -Tabelle . 

Dies setzt voraus , daS die zur Identif ikation der BDocs 
verwendeten Schlussel im Gesamt system eindeutig sind, 
also kein Schlussel in dem gesamten Datenbank-Netzwerksy- 
stem (DBNS) mehrfach zur Bezeichnung unterschiedlicher 
Replikationsobjekt-Instanzen verwendet wird. Diese Vor- 
aussetzung ist bei GUIDs selbstverstandlich erfiillt. 

Die Figuren 11 und 12 erlautern die in Figur 10 als Feld 
914 z us ammenge fasten Schritte . Nach dem Start 1101 des 
Programmoduls und der Ubernahme des BDoc (Schritt 1102) , 
werden zunachst in dem Schritt 1103 alle BDocs zu einem 
"Cluster" zusammengefafit, die durch Links (d.h. Pointer 
in der konsolidierten Datenbank CD) miteinander verbunden 
sind. Konkret wird eine Liste der Primarschlussel aller 
BDoc-Instanzen erstellt, die miteinander durch Links ver- 
knupft sind. Sie konnen unterschiedlichen BDoc -Typen an- 
gehoren und werden gemeinsam in dem nachf olgenden Algo- 
rithmus bearbeitet. Dies ist dadurch moglich, dafi typ- 
ubergreifend eindeutige Schlussel (beispielsweise GUIDs) 
verwendet werden. Diese gemeinsame Verarbeitung ist wich- 
tig fur die Performance des Systems. Durch die Verarbei- 
tung der BDocs mit typubergreif enden Algorithmen kann die 
Bearbeitungszeit wesentlich verkurzt werden. 



WO 00/79408 




PCT/DE0O/01S52 



44 



Soweit vorstehend davon die Rede ist, dafi "alle" Verknup- 

fungen durch Links zu einem Cluster zusammengef aEt wer- 

den, gilt dies selbstverstandlich nur, soweit dem keine 

Beschrankungen hinsichtlich der Verteilung von Daten 

(beispielsweise wegen deren Vertraulichkeit) entgegenste- 
hen. 

Fiir alle BDocs eines Clusters lauft die in Figur 11 dar- 
gestellte, aus den Schritten 1104 bis 1108 bestehende 
for-Schleife ab. Dabei werden ahnlich wie bei den Schrit- 
ten 907 und 908 von Figur 9 die aktuellen Adressaten be- 
atxmmt und mit den alten Adressaten verglichen, um hin- 
zugekommene (neue) und nicht mehr aktuelle (Ex) Adressaten 
zu bestimmen. Die Bestimmung der aktuellen Adressaten er- 
fordert dabei keinen Ruckgriff auf die Subskriptionsta- 
belle, sondem kann unmittelbar aus der LOT des BDoc ent- 
nommen werden, weil in diesem Algorithmus keine Berech- 
nung von Adressaten mittels Assignment erforderlich ist. 

Die nachfolgende Aktualisierung der LUTs in dem Schritt 
1109 erfolgt analog wie bei Figur 9. wichtig far die Per- 
formance ist, daS dieser Schritt fur alle BDocs des 
Clusters gemeinsam nach vollstandiger Abarbeitung der 
vorausgegangenen Schleife erfolgt. 

Auch die in Figur 12 dargestellten Schritte zur Veranlas- 
sung der erforderlichen Insert- und Delete-Operationen 
erfolgen analog Figur 10, allerdings in einer weiteren, 
aus den Schritten 1110 bis me bestehenden for-Schleife 
in der nacheinander alle BDocs des Clusters abgearbeitet 
werden, far die aus der vorhergehenden Schleife modifi- 
zierte Adressaten resultieren. 

Da das Realignment ein Rechenzeit-aufwendiger Vorgang 
ist, kann eine Parallelbearbeitung der in der Realignment 
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Queue RAQ anstehenden Jobs zweckmaSig sein. Dies ist zu- 
lassig, wobei jedoch darauf geachtet werden muE, daS die 
Bearbeitung der Realignment- Jobs fur eine BDoc-Instanz in 
der gleichen Reihenfolge erfolgt, in der die Realignment- 
Jobs (im Rahmen der Replikation) erzeugt worden sind. Mit 
anderen Wort en mussen die Realignment- Jobs einer Replika- 
tionsobjekt-Instanz stets in der Reihenfolge abgearbeitet 
werden, in der sie erzeugt worden sind. Dies lafit sich im 
Falle einer Parallel is ierung beispielsweise dadurch ge- 
wahrleisten, daJS alle Realignment -Jobs einer BDoc-Instanz 
stets in die gleiche Realignment Queue eingestellt und 
damit zwingend nacheinander prozessiert werden. 

Wie erlautert dient das Realignment -Modul RA nicht nur 
zur Aktualisierung der LUTs, sondern auch dazu, die in- 
folge von LUT-Anderungen notwendigen Insert- und Delete- 
Operationen zu veranlassen. Zur Ausfiihrung dieser 
Anderungsoperationen wird ein Extract- Job generiert, der 
von dem Extractor -Modul EXT unabhangig und asynchron ab- 
gearbeitet wird. Das Extractor -Modul wird auch in anderem 
Zusammenhang verwendet, urn BDocs zu erzeugen, die zur 
Durchfuhrung einer Insert- oder Delete -Operation in einer 
der beteiligten Datenbanken dienen. . 

Das in Figur 13 dargestellte Ablaufschema verdeutlicht 
einen fur das Extractor-Modul geeigneten Algorithmus . 
Nach dem Start 1301 des Moduls wird in dem Schritt 13 02 
ein Job aus der Extractor-Queue EXQ mittels eines Queue - 
Readers, der die sequent ielle Abarbeitung sicherstellt , 
ubernommen. Der Extractor- Job enthalt den Primarschlussel 
des BDocs, auf das er sich bezieht und die Adressen 
(Site- IDs) von einem oder mehreren Knotensystemen, in 
denen die Insert- oder Delete-Operation durchgefuhrt wer- 
den sollen. In dem Schritt 1304 werden, sofern es sich urn 
eine Insert-Operation handelt, die Daten des BDoc aus der 
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konsolidierten Datenbank CD ausgelesen. AnschlieSend wer- 
den in dem Schritt i 30 5 die Adressen der Adressaten in 
den BDoc-Kopf BDoc-H (wiederum durch Verweis auf eine 
Adressenliste AL) eingetragen. SchlieUlich wird in dem 
Schritt 1306 das extrahierte BDoc an die FluSsteuerung FC 
ubergeben und der FluS gestartet. Der Schritt 1307 mar- 
kiert das Ende des Moduls. 

Anderungen der LUT und auf Basis solcher Anderungen not- 
wendige Insert- und Delete-Operationen konnen nicht nur 
aus von den Knotensystemen NS iibermittelten Anderungsin- 
formationen resultieren. Vielmehr fuhren, wie bereits be- 
schrxeben, Anderungen, die von dem Systemverwalter uber 
dxe Admxnistrationsstation AS vorgenommen werden, in 
vxelen Fallen zu einer Anderung der Informationsvertei- 
lung innerhalb des Datenbanksys terns . Insbesondere werden 
haufxg Anderungen der Subskriptionstabelle ST erforder- 
lich, beispielsweise wenn neue AuSendienstmitarbeiter 
eingestellt werden und deren Laptops als Knotensysteme in 
das Datenbank-Netzwerksystem DBNS eingebunden werden sol- 
len oder wenn sich Anderungen hinsichtlich der Zuordnung 
der Knotensysteme NS zu den Vertriebsgebieten ergeben 
(beispielsweise einer oder mehrere der Aufiendienstmitar- 
bexter in ein anderes Vertriebsgebiet wechseln) . 

Derartige Anderungen werden mittels eines Programmoduls 
in das System eingearbeitet, das als Subskriptionsprufmo- 
dul SC (Subscription Checker, bezeichnet wird. In den Fi- 
guren 14 und 15 sind Ablaufdiagramme von Algorithmen fur 
zwei Typen von Subskriptionsprvifmodulen SC dargestellt 
die abhangig von dem Typ des BDocs verwendet werden. Das 
" Fl9 - 14 dar 3estellte Bulk-Subskriptionsprufmodul wird 
fur die BDoc-Typen verwendet, die mit der Bulk-Replika- 
tion gemafi Fig. 6 rep ii 2 iert werden, wahrend das in Fig 
15 dargestellte Objekt-Subskriptionsprufmodul f ur die 
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BDocs verwendet wird, die mit der intelligenten Replika- 
tion gemaS Figur 7 repliziert werden. 

Nach dem Start 1401 des Bulk-Subskriptionsprufmoduls wird 
in dem Schritt 14 02 ein in der Administrationsstation AS 
generierter Bulk -Subskript ions -Job ubernommen. Er enthalt 
fur ein im Wege der Bulk-Replikation verteiltes BDoc (zum 
Beispiel Produkt-Stammdaten) Links zu alien nach dem ak- 
tuellen Stand gultigen Adressaten. In dem Schritt 1403 
werden aus der Bulk-LUT die dort registrierten Adressaten 
des entsprechenden BDocs herausgelesen. Anschliefiend wer- 
den in dem Schritt 1404 mittels der in dem Bulk-Subskrip- 
tions-Job enthaltenen Links die entsprechenden Subskri- 
benten aus der Subskript ions -Tabe lie ST ausgelesen. Durch 
Vergleich der in den Schritten 14 03 und 14 04 gewonnenen 
Daten werden in dem Schritt 14 05 neue und nicht mehr ak- 
tuelle (Ex) Adressaten bestimmt. Sofern eine nachfolgende 
Abfrage 1406, ob neue Adressaten festgestellt wurden, zu 
einem positiven Ergebnis fuhrt, werden in einem Schritt 
1407 entsprechende Eintrage fur die Bulk-LUT generiert 
und eingetragen. Aufierdem werden in dem Schritt 1408 
Extract -Jobs generiert und in die Extractor-Queue EXQ 
eingestellt, durch deren Abarbeitung die entsprechenden 
Insert -Operationen veranlafit werden. 

Entsprechend werden im Falle einer positiven Antwort auf 
eine weitere Abfrage 14 09, ob Ex-Adressaten festgestellt 
wurden, in einem Schritt 1410 Loschauf trage generiert, 
durch die die entsprechenden Eintrage in der Bulk-LUT ge- 
loscht werden. Auch hier werden in einem Schritt 1411 
Extract or -Jobs generiert, bei deren Abarbeitung BDocs mit 
Loschvermerken erzeugt werden, die zum Loschen der ent- 
sprechenden Daten in den Knotensystemen fiihren. Der 
Schritt 1412 markiert das Ende des Moduls . 
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Nach dem Start 1501 des in Fig. 15 dargestellten Objekt- 
SubskriptionsprQf module wird in dem Schritt 1502 ein von 
der Administrationsstation AS generierter Objekt-Sub- 
skriptions-Job ubernommen, der eine Zuordnung zwischen 
entsprechenden Inhalten verteilungskritischer Datenfelder 
und den betreffenden Adressaten enthalt. Er enthalt also 
bexspielsweise die Angabe, daS fur ein Vertriebsgebiet A 
AuEendienstmitarbeiter 1, 3, 5 und 8 und far ein Ver- 
triebsgebiet B AuSendienstmitarbeiter 2, 4, 6 und 7 zu- 
standig sein sollen. 

in einem nachf olgenden Schritt 1503 werden aus der konso- 
lxdxerten Datenbank CD die Schlussel aller BDocs heraus- 
gelesen, fur die diese Bedingungen erfullt sind, also 
bexspielsweise alle Kunden, die in einem ihr Vertriebsge- 
bxet markierenden Datenfeld den Eintrag A haben. SchlieS- 
lxch werden in einem Schritt 1504 fur alle diese BDocs 
Realignment-Jobs generiert und die Realignment Queue RAQ 
exngestellt, so dae sie (unabhangig und asynchron) von 
dem anhand der Figuren 9 bis 12 beschriebenen Realign- 
ment -Modul bearbeitet werden. Danach ist der Modul been- 
det (1505) . 

Die Erfindung ermoglicht eine in mehrfacher Hinsicht be- 
sonders vorteilhafte Losung der mit der Datenpflege in 
exnem Netzwerk teilweise replizierten Datenbanksysteme 
verbundenen Probleme . Insbesondere erlaubt sie mit guter 
Performance den Aufbau und Betrieb von Datenbank-Netz- 
werksystemen mit einer sehr grofien Teilnehmerzahl (mehr 
als 10 000 Teilnehmer) und ermoglicht eine aufierordent- 
lich flexible und verhaltnismaSig einfache Anpassung an 
dxe Bedurfnisse des jeweiligen Betreibers des Datenbank- 
Netzwerksystems . 
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Ein charakteristisches Element ist das Zusammenwirken von 
asynchron und unabhangig voneinander arbeitenden Program - 
modulen, die jeweils eine definierte Aufgabe erfullen und 
uber definierte Schnittstellen miteinander kommunizieren. 
Eine zentrale Funktion ist die Replikation auf Basis von 
Lookup -Tabe lien, aus denen die zu dem jeweiligen Zeit- 
punkt aktuellen Adressaten eines Replikationsobj ektes 
(ohne Berucksichtigung eventueller Ande rungen aufgrund 
der in dem Replikationsobj ekt codierten Anderungs informa- 
tion) herausgelesen werden, ohne da£ eine Prozessierung 
von Daten erf orderlich ist . Soweit die Anderungs informa- 
tion eine Anderung hinsichtlich der Verteilung an die 
Adressaten in dem Net zwerksys tern nach sich zieht, werden 
die Iiookup-Tabellen mittels eines asynchron durchgefiihr- 
ten Realignment- Prozesses angepaSt . Die Ubertragung von 
Neuanlagen und Loschungen an die zustandigen Adressaten 
erfolgt ebenfalls im Rahmen des Realignment, nachdem neue 
Adressaten und Ex-Adressaten festgestellt wurden. 



WO 00/79408 




PCT/DEOO/01552 



50 



Patentanspruche 

Verfahren zur Datenpflege in einem of f line-verteilten 
Datenbank-Netzwerksystems (DBNS) , welches ein Zen- 
tralsystem (CS) mit einer zentralen Datenbank (CD) 
und eine Mehrzahl von Knotensystemen (NS) mit lokalen 
Datenbanken (LD) umfaSt, wobei 

die lokalen Datenbanken (LD) mindestens teilweise un- 
terschiedliche Teilmengen der Daten der zentralen Da- 
tenbank (CD) enthalten, 

Anderungsinformationen zu den in den Datenbanken 
(CD, LD) des Datenbank-Netzwerksystems (DBNS) gespei- 
oherten Daten in einer Mehrzahl der Knotensysteme 
(NS) erfaEt werden, 

die Anderungsinformationen bei bestehender Online- 
Verbindung als in mehreren unterschiedlichen Typen 
strukturierte, einen Identif ikationsschlussel enthal- 
tende Replikationsobjekte von den Knotensystemen zu 
dem Zentralsystem oder von dem Zentralsystem zu den 
Knotensystemen ubertragen werden, 

die Replikationsobjekte bei fehlender Online -Verbin- 
dung in einer Aus gangs schlange fur eine spatere Uber- 
tragung bereitgestellt werden, 

die Replikationsobjekte mit den Anderungsinformatio- 
nen in dem Zentralsystem (CS) in einem Replikations- 
Algorithmus mittels mindestens einer Lookup-Tabelle 
(LOT) den Knotensystemen (NS) , an die sie ubermittelt 
werden sollen, als Adressaten zugeordnet werden und 
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die mindestens eine Lookup- Tabelle unter Berucksich- 
tigung der Ande rungs in formationen in einem Realign- 
ment -Algor it hmus aktualisiert wird. 

2. Verfahren nach Anspruch 1, bei welchem die 
Replikationsobjekte eine Zerlegung der gesamten zwi- 
schen den Datenbanken ( CD , LD ) des Datenbank-Netzwerk- 
systems (DBNS) offentliche Datenmengen bilden. 

3. Verfahren nach einem der Anspruche 1 oder 2, bei wel- 
chem die Replikationsobjekte eine Identif ikation 
ihres Typs und eine Identif ikation der Datenbankope- 
ration Update, Insert oder Delete, die der in dem Re- 
plikationsobjekt codierten Anderungs information ent- 
spricht , enthalten . 

4. Verfahren nach einem der vorhergehenden Anspruche, 
bei welchem die Verarbeitung der Replikationsobjekte 
in dem Zentralsystem (CS) mittels einer Flufisteuerung 
(FC) gemaS einer fur den Typ des Replikationsobj ektes 
spezifischen FluSdef inition (FD) gesteuert wird. 

5. Verfahren nach einem der vorhergehenden Anspruche, 
bei welchem zur Ubertragung der Anderungs information 
von dem Zentralsystem (CS) zu den Knotensystemen (NS) 
Remote-Calls (qRFC) verwendet werden, die so ausge- 
bildet sind, dafi fur mehrere in einer Ausgangs- 
schlange stehende Calls benotigte gemeinsame Daten 
nur einmal gespeichert werden mussen. 

6. Verfahren nach einem der vorhergehenden Anspruche, 
bei welchem mindestens zwei Typ en von Lookup -Tabe 11 en 
verwendet werden, von denen ein erster Typ (B-LUT) 
eine Zuordnung zwischen Typen von Replikationsobj ek- 
ten und den Adressaten enthalt und ein zweiter Typ 
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(O-LUT) eine Zuordnung zwischen Instanzen von Repli - 
kationsobjekten und den Adressaten enthalt. 

Verfahren nach Anspruch 6, bei welchem mehrere 
Lookup-Tabellen des zweiten Typs (O-LUT) verwendet 
werden, die jeweils Zuordnungen zwischen den In- 
stanzen eines Replikationsobjekt-Typs und den Adres- 
saten der Instanzen enthalten. 

Verfahren nach einem der Anspruche 6 oder 7, bei wel- 
chem in Abhangigkeit von dem Typ des Replikationsob- 
]ektes unterschiedliche Typen von Replikations-Algo- 
rithmen durchgefiihrt werden, wobei 

mittels eines ersten Replikations-Algorithmus-Typs 
(Bulk Replication) eine bestimmte Teilmenge der Re- 
plikationsobjekte in Abhangigkeit von ihrem Typ unter 
Verwendung einer Lookup -Tabe lie des ersten Typs (B- 
LUT) den Adressaten zugeordnet werden und 
mittels eines zweiten Replikations-Algorithmus-Typs 
(Intelligent Replication) eine bestimmte, mit der er- 
sten Teilmenge nicht Qberlappende Teilmenge der Re- 
plikationsobjekte in Abhangigkeit von ihrer Instanz 
unter Verwendung einer Lookup -Tabe lie des zweiten 
Typs (O-LUT) den Adressaten zugeordnet wird. 

Verfahren nach Anspruch 8, bei welchem mittels eines 
dritten Replikations-Algorithmus-Typs (Dependent Re- 
plication) eine bestimmte dritte Teilmenge von Repli - 
kationsobjekten, die mit der ersten und der zweiter, 
Teilmenge nicht uberlappt, in Abhangigkeit von der 
fur ein ubergeordnetes Replikationsobjekt in einer 
Lookup-Tabelle des zweiten Typs (O-LUT) eingetragenen 
Zuordnung den Adressaten zugeordnet werden. 
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10. Verfahren nach einem der vorhergehenden Anspruche, 
bei welchem der Realignment-Algorithmus unabhangig 
von dem Replikations-Algorithmus und asynchron zu 
diesem durchgefuhrt wird. 

11. Verfahren nach einem der Anspruche 3 bis 10, bei wel- 
chem in dem Replikations-Algorithmus auf Basis einer 
Abfrage (703) der I dent if ikation der Datenbankope ra- 
tion ein Job fur den Realignment-Algorithmus gene- 
riert wird, wenn die Datenbankoperation, die der in 
dem bearbeiteten Replikationsobjekt codierten Ande- 
rungs information entspricht, eine Neuanlage (Insert) 
oder Loschung (Delete) ist . 

12. Verfahren nach einem der Anspruche 3 bis 10, bei wel- 
chem in dem Replikations-Algorithmus auf Basis einer 
Abfrage (703,706) der Identif ikation der Datenbank- 
operation ein Job fur den Realignment-Algorithmus ge- 
neriert wird, wenn die Datenbankoperation, die der in 
dem bearbeiteten Replikationsobjekt codierten Ande- 
rungsinformation entspricht, eine Modif ikation 
(Update) ist und die Daten in mindestens einem vorbe- 
stimmten verteilungskritischen Datenfeld des Replika- 
tionsobjektes geandert wurden. 

13. Verfahren nach den Anspriichen 8 und 11 oder 12, bei 
welchem die Abfrage (703) der Identif ikation der 
Datenbankoperation in dem Ablauf des zweiten Replika- 
tions-Algorithmus -Typs (Intelligent Replication) er- 
f olgt . 

14. Verfahren nach einem der Anspruche 10 bis 13, bei 
welchem in den Realignment-Algorithmus der Inhalt des 
verteilungskritischen Datenfeldes mit in einer Sub- 
skript ions tabe lie ST vorgegebenen Verteilungsregeln 
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verglichen und auf Basis dieses Vergleiches die 
Lookup- Tabelle (O-LUT) aktualisiert wird. 

15. Verfahren nach einem der Anspruche 10 bis 14, bei 
welchem in den Realignment-Algorithmus eine Lookup- 
Tabelle eines Replikationsobjektes (O-LUT) unter Be- 
rucksichtigung der Lookup- Tabelle (SRO-LUT) eines 
iibergeordneten Replikationsobjektes aktualisiert 



16 



wird. 



Verfahren nach einem der Anspruche 10 bis 15, bei 
welchem in dem Realignment-Algorithmus zunachst alle 
unter Berucksichtigung der in dem Replikationsobjekt 
codierten Anderungsinf ormation aktuellen Adressaten 
bestimmt, diese mit den in einer Lookup -Tabelle 
(O-LUT) verzeichneten Adressaten verglichen werden, 
urn zusatzliche neue Adressaten und nicht mehr aktu- 
elle Ex- Adressaten zu bestimmen und die Information 
uber die neuen und die Ex-Adressaten zur Ubernahme in 
die Lookup-Tabelle (O-LUT) bereitgestellt wird. 

17. Verfahren nach Anspruch 16, bei welchem in dem 

Realignment-Algorithmus nach der Bestimmung der neuen 
und der Ex-Adressaten die notwendigen Insert -Opera - 
tionen bei den neuen Adressaten und Delete-Operatio- 
nen bei den Ex-Adressaten eingeleitet werden, durch 
die den neuen Adressaten der vollstandige Dateninhalt 
des in dem Realignment-Algorithmus bearbeiteten Re- 
plikationsobjektes ubermittelt wird bzw. der dem Re- 
plikationsobjekt entsprechende Dateninhalt in den Da- 
tenbanken der Ex-Adressaten geldscht wird. 

18. Verfahren nach Anspruch 17, bei welchem die notwendi- 
gen Insert- oder Delete -Operationen mittels eines ge- 
sonderten Extrakt-Algorithmus, der unabhangig von dem 
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Realignment -Algorithmus und asynchron zu diesem ab- 
lauft, eingeleitet werden, in welchem Replikationsob- 
jekte erzeugt werden, die zur Durchf uhrung der 
Insert -Operation an die neuen Adressaten bzw. zur 
Durchfuhrung der Delete -Operationen an die Ex-Adres- 
saten ubermittelt werden. 

19. Verfahren nach einem der Anspruche 17 oder 18, bei 
welchem die neuen Adressaten und die Ex-Adressaten 
erst in die Lookup -Tabelle LUT ubernommen werden, 
nachdem sichergestellt ist, dafi die notwendigen 
Insert- oder Delete -Operationen ausgefuhrt werden, 
bevor erstmalig in einem Replikationsalgorithmus auf 
die geanderte Lookup- Tabelle zugegriffen wird. 

20. Verfahren nach einem der vorhergehenden Anspruche, 
bei welchem zur Berucksichtigung von in den Replika- 
tionsobjekten codierten Verknupf ungen zu anderen Re- 
plikationsobjekten in dem Realignment -Algorithmus 
Cluster von miteinander verknupf ten Replikationsob- 
jekten gebildet werden, fur die in einer for-Schleife 
zunachst alle unter Berucksichtigung der in dem Re- 
plikationsobjekt codierten Ande rungs information 
aktuellen Adressaten bestimmt, diese mit den in einer 
Lookup -Tabelle (O-LUT) verzeichneten Adressaten 
verglichen werden, urn zusatzliche neue Adressaten und 
nicht mehr aktuelle Ex-Adressaten zu bestimmen und 
die Information uber die neuen und die Ex-Adressaten 
fur alle Replikationsobjekte des Clusters nach Been- 
digung der for-Schleife zur Ubernahme in die Lookup- 
Tabelle (O-LUT) bereitgestellt wird. 
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21. Verfahren nach einem der vorhergehenden Anspriiche, 
bei welchem die Replikationsobjekte durch in dem 
gesamten Datenbank-Netzwerksystem eindeutige Schlus- 
sel identifiziert sind. 

22. Computerprogrammprodukt, das direkt in den Speicher 
eines digitalen Computers geladen werden kann und 
Softwarecodeabschnitte umfaSt, mit denen die Schritte 
des Verfahrens nach einem der Anspruche 1 bis 20 aus- 
gefuhrt werden, wenn das Produkt auf einem Computer 

lauf t . 

23 . Computergeeignetes Speichermedium mit einem Computer- 
programmprodukt nach Anspruch 22. 



Datenbank-Netzwerksystem enthaltend ein Computerpro- 
grammprodukt nach Anspruch 22. 
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